From issues at jboss.org  Fri Dec  1 03:08:01 2017
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Fri, 1 Dec 2017 03:08:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9589) Upgrade JBossXACML to 2.0.10
In-Reply-To: <JIRA.12723036.1512115641000@Atlassian.JIRA>
References: <JIRA.12723036.1512115641000@Atlassian.JIRA>
	<JIRA.12723036.1512115641000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723036.1512115641000.68700.1512115681004@Atlassian.JIRA>


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

Yeray Borges moved JBEAP-13894 to WFLY-9589:
--------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-9589  (was: JBEAP-13894)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Security
                     (was: Security)


> Upgrade JBossXACML to 2.0.10
> ----------------------------
>
>                 Key: WFLY-9589
>                 URL: https://issues.jboss.org/browse/WFLY-9589
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Yeray Borges
>




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

From issues at jboss.org  Fri Dec  1 04:23:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 1 Dec 2017 04:23: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.69162.1512120180097@Atlassian.JIRA>


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

Jan Kalina commented on ELY-457:
--------------------------------

Added analysis document

> 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
>            Assignee: Jan Kalina
>             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  Fri Dec  1 04:32:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Fri, 1 Dec 2017 04:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1392) Undeploy doesn't remove
 Data content if server is in --admin-only mode
In-Reply-To: <JIRA.12604281.1455680639000@Atlassian.JIRA>
References: <JIRA.12604281.1455680639000@Atlassian.JIRA>
	<JIRA.12604281.1455680639000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12604281.1455680639000.69210.1512120720246@Atlassian.JIRA>


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

Tomas Hofman commented on WFCORE-1392:
--------------------------------------

As for full replace deployment, the handler already removes the content in both modes - no changes are required and it's also not affected by modifications in DeploymentRemoveHandler.

{code}
DeploymentFullReplaceHandler:
  remove old resource
  contentRepository.addContent(new content) or contentRepository.syncContent(new content)
  create new resource
  if (ENABLED):
    DeploymentHandlerUtil.replace(...) // basically just removes old services and creates new ones
  else:
    DeploymentHandlerUtil.undeploy(...)
  complete step:
    if (new and old content hashes differ, or new content is unmanaged):
      contentRepository.removeContent(...)
    if (is managed content):
      contentRepository.addContentReference(...)
{code}


The domain controller's DeploymentFullReplaceHandler works very similarly, also removing content in the complete step of the main step (so in both modes).

>  Undeploy doesn't remove Data content if server is in --admin-only mode
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-1392
>                 URL: https://issues.jboss.org/browse/WFCORE-1392
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>    Affects Versions: 2.1.0.CR2
>            Reporter: Chao Wang
>            Assignee: Tomas Hofman
>            Priority: Minor
>
> {noformat}
> Steps to Reproduce:
> 1. Start server instance using --admin-only flag
> 2. Deploy application using CLI command.
> ~~~
> deploy /valid/path/WebApp.war --runtime-name=WebApp.war --name=WebApp.war
> ~~~
> 3. Undeploy application using CLI command:
> ~~~
> undeploy WebApp.war
> ~~~
> 4. Application will be undeployed but content from 'data' directory are not removed. 
> {noformat}
> Lines: 
> https://github.com/wildfly/wildfly-core/blob/b1a4439f442f7984e681840c0f8d18089a87c920/server/src/main/java/org/jboss/as/server/deployment/DeploymentRemoveHandler.java#L73
> https://github.com/wildfly/wildfly-core/blob/e737eff554ee433ca54835154fd67725fd52f63e/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L1010
> runningMode value is ADMIN_ONLY will bypass that step in DeploymentRemoveHandler.java leads to this behavior. 



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

From issues at jboss.org  Fri Dec  1 05:21:00 2017
From: issues at jboss.org (Alexis Hassler (JIRA))
Date: Fri, 1 Dec 2017 05:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1359) Missing configuration
 elements in the XA DataSources
In-Reply-To: <JIRA.12722476.1511811739000@Atlassian.JIRA>
References: <JIRA.12722476.1511811739000@Atlassian.JIRA>
	<JIRA.12722476.1511811739000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722476.1511811739000.69451.1512123660181@Atlassian.JIRA>


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

Alexis Hassler updated JBJCA-1359:
----------------------------------
    Forum Reference: https://developer.jboss.org/message/978578


> Missing configuration elements in the XA DataSources
> ----------------------------------------------------
>
>                 Key: JBJCA-1359
>                 URL: https://issues.jboss.org/browse/JBJCA-1359
>             Project: IronJacamar
>          Issue Type: Feature Request
>          Components: Embedded
>    Affects Versions: 1.4.5
>            Reporter: Alexis Hassler
>
> When I start a XA DataSource with IJ Embedded, some configuration are not used, including <prepared-statement-cache-size> and <valid-connection-checker>.
> These elements are correctly loaded for none-XA datasources but are ignored for XA datasources.
> I've isolated the problem in a simple test case at https://gitlab.com/hasalex/sw-ijembed/.
> The failing test can be seen in the CI : https://gitlab.com/hasalex/sw-ijembed/-/jobs



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

From issues at jboss.org  Fri Dec  1 05:41:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 1 Dec 2017 05:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2157) DMN Editor: Contexts: Add
 special behaviour of last row
In-Reply-To: <JIRA.12722941.1512047645000@Atlassian.JIRA>
References: <JIRA.12722941.1512047645000@Atlassian.JIRA>
	<JIRA.12722941.1512047645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722941.1512047645000.69554.1512124860654@Atlassian.JIRA>


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

Michael Anstis commented on DROOLS-2157:
----------------------------------------

Things to do:

* Add a new {{ContextEntry}} to the definition for the last row.
* Use a default (variable) "name" for the {{ContextEntry}}. This may become irrelevant if the grid rendering changes to ignore the "name" column.
* Prevent editing the "name" for the last {{ContextEntry}}
* Prevent dragging the last row, or other rows past the last row.
* Prevent deleting the last row (it is impossible to delete rows at the moment!)
* Insert new {{ContextEntry}} rows before the last row. 

> DMN Editor: Contexts: Add special behaviour of last row
> -------------------------------------------------------
>
>                 Key: DROOLS-2157
>                 URL: https://issues.jboss.org/browse/DROOLS-2157
>             Project: Drools
>          Issue Type: Enhancement
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> The last row of a {{Context}} should span all columns and populate the last {{ContextEntry}} in the {{Context}}. It should not have a variable. This is the XML for a _regular_ row and the _final_ row:
> {code}
> <semantic:context id="_f4f86e5f-e3e3-4b99-9260-8086764e598f">
>       <semantic:contextEntry>
>         <semantic:variable id="_779ca919-15d8-48d0-a9f0-e0203e60fac6" name="in1"/>
>         <semantic:literalExpression id="_4b8b8cc1-a56c-4673-8334-96e178cd04a4">
>           <semantic:text>"literal exp" </semantic:text>
>         </semantic:literalExpression>
>       </semantic:contextEntry>
>       <semantic:contextEntry>
>         <semantic:literalExpression id="_297181da-d0d5-4137-960b-34836d5570e5">
>           <semantic:text>"result"  </semantic:text>
>         </semantic:literalExpression>
>       </semantic:contextEntry>
>     </semantic:context>
> {code}



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

From issues at jboss.org  Fri Dec  1 07:02:02 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 1 Dec 2017 07:02:02 -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.69866.1512129722323@Atlassian.JIRA>


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

Jan Kalina reassigned ELY-283:
------------------------------

    Assignee: Jan Kalina


> 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
>
>
> 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  Fri Dec  1 07:13:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 1 Dec 2017 07:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2157) DMN Editor: Contexts: Add
 special behaviour of last row
In-Reply-To: <JIRA.12722941.1512047645000@Atlassian.JIRA>
References: <JIRA.12722941.1512047645000@Atlassian.JIRA>
	<JIRA.12722941.1512047645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722941.1512047645000.69888.1512130380057@Atlassian.JIRA>


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

Michael Anstis commented on DROOLS-2157:
----------------------------------------

Changes:

https://github.com/manstis/appformer/commit/b47182f6717b7c84089a7b705436e4c90d285a65
https://github.com/manstis/kie-wb-common/commit/5618dad130f88fc435da41585e311811eb326243

Unit tests to follow.

> DMN Editor: Contexts: Add special behaviour of last row
> -------------------------------------------------------
>
>                 Key: DROOLS-2157
>                 URL: https://issues.jboss.org/browse/DROOLS-2157
>             Project: Drools
>          Issue Type: Enhancement
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> The last row of a {{Context}} should span all columns and populate the last {{ContextEntry}} in the {{Context}}. It should not have a variable. This is the XML for a _regular_ row and the _final_ row:
> {code}
> <semantic:context id="_f4f86e5f-e3e3-4b99-9260-8086764e598f">
>       <semantic:contextEntry>
>         <semantic:variable id="_779ca919-15d8-48d0-a9f0-e0203e60fac6" name="in1"/>
>         <semantic:literalExpression id="_4b8b8cc1-a56c-4673-8334-96e178cd04a4">
>           <semantic:text>"literal exp" </semantic:text>
>         </semantic:literalExpression>
>       </semantic:contextEntry>
>       <semantic:contextEntry>
>         <semantic:literalExpression id="_297181da-d0d5-4137-960b-34836d5570e5">
>           <semantic:text>"result"  </semantic:text>
>         </semantic:literalExpression>
>       </semantic:contextEntry>
>     </semantic:context>
> {code}



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

From issues at jboss.org  Fri Dec  1 07:20:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 1 Dec 2017 07:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2157) DMN Editor: Contexts: Add
 special behaviour of last row
In-Reply-To: <JIRA.12722941.1512047645000@Atlassian.JIRA>
References: <JIRA.12722941.1512047645000@Atlassian.JIRA>
	<JIRA.12722941.1512047645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722941.1512047645000.69891.1512130800287@Atlassian.JIRA>


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

Michael Anstis updated DROOLS-2157:
-----------------------------------
    Tester: Jozef Marko


> DMN Editor: Contexts: Add special behaviour of last row
> -------------------------------------------------------
>
>                 Key: DROOLS-2157
>                 URL: https://issues.jboss.org/browse/DROOLS-2157
>             Project: Drools
>          Issue Type: Enhancement
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> The last row of a {{Context}} should span all columns and populate the last {{ContextEntry}} in the {{Context}}. It should not have a variable. This is the XML for a _regular_ row and the _final_ row:
> {code}
> <semantic:context id="_f4f86e5f-e3e3-4b99-9260-8086764e598f">
>       <semantic:contextEntry>
>         <semantic:variable id="_779ca919-15d8-48d0-a9f0-e0203e60fac6" name="in1"/>
>         <semantic:literalExpression id="_4b8b8cc1-a56c-4673-8334-96e178cd04a4">
>           <semantic:text>"literal exp" </semantic:text>
>         </semantic:literalExpression>
>       </semantic:contextEntry>
>       <semantic:contextEntry>
>         <semantic:literalExpression id="_297181da-d0d5-4137-960b-34836d5570e5">
>           <semantic:text>"result"  </semantic:text>
>         </semantic:literalExpression>
>       </semantic:contextEntry>
>     </semantic:context>
> {code}



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

From issues at jboss.org  Fri Dec  1 07:37:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 1 Dec 2017 07:37: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.69967.1512131820292@Atlassian.JIRA>


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

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

Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*

> 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
>
>
> 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  Fri Dec  1 08:14:00 2017
From: issues at jboss.org (=?UTF-8?Q?Bartosz_Spyrko-=C5=9Amietanko_=28JIRA=29?=)
Date: Fri, 1 Dec 2017 08:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2673) HTTP redirect if both http
 and https socket-binding is configured for http-interface
In-Reply-To: <JIRA.12687620.1492085070000@Atlassian.JIRA>
References: <JIRA.12687620.1492085070000@Atlassian.JIRA>
	<JIRA.12687620.1492085070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12687620.1492085070000.70124.1512134040619@Atlassian.JIRA>


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

Bartosz Spyrko-?mietanko reassigned WFCORE-2673:
------------------------------------------------

    Assignee:     (was: Bartosz Spyrko-?mietanko)


> HTTP redirect if both http and https socket-binding is configured for http-interface
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2673
>                 URL: https://issues.jboss.org/browse/WFCORE-2673
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Ondrej Lukas
>
> In case when both http and https socket-binding is configured for management http-interface and http port is accessed then server tries to redirect automatically to https port. Access http is not possible.
> It causes that it is impossible to connect to http-interface with clients which do not supports https (even if http port is provided by application server), i.e. following ModelControllerClient is not able to connect to http-interface when both http and https socket-binding is configured:
> {code}
> ModelControllerClient client = ModelControllerClient.Factory
>         .create(new ModelControllerClientConfiguration.Builder()
>                 .setProtocol("remote+http")
>                 .setPort(9990)
>                 .setHostName("localhost")
>                 .setConnectionTimeout(10000).build())
> {code}
> See:
> {code}
> curl -v -H 'Upgrade: jboss-remoting' http://localhost:9990
> * Rebuilt URL to: http://localhost:9990/
> * Hostname was NOT found in DNS cache
> *   Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 9990 (#0)
> > GET / HTTP/1.1
> > User-Agent: curl/7.38.0
> > Host: localhost:9990
> > Accept: */*
> > Upgrade: jboss-remoting
> > 
> < HTTP/1.1 302 Found
> < Connection: keep-alive
> < Location: https://localhost:9993/
> < Content-Length: 0
> < Date: Thu, 13 Apr 2017 11:59:56 GMT
> < 
> * Connection #0 to host localhost left intact
> {code}



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


From issues at jboss.org  Fri Dec  1 09:13:01 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 1 Dec 2017 09:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9590)
 Auto-[create|delete]-jms-queues cannot be disabled
In-Reply-To: <JIRA.12723095.1512137513000@Atlassian.JIRA>
References: <JIRA.12723095.1512137513000@Atlassian.JIRA>
	<JIRA.12723095.1512137513000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723095.1512137513000.70392.1512137581069@Atlassian.JIRA>


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

Jeff Mesnil moved JBEAP-13898 to WFLY-9590:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-9590  (was: JBEAP-13898)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JMS
                           (was: ActiveMQ)
                           (was: JMS)
    Affects Version/s:     (was: 7.2.0.GA)


> Auto-[create|delete]-jms-queues cannot be disabled
> --------------------------------------------------
>
>                 Key: WFLY-9590
>                 URL: https://issues.jboss.org/browse/WFLY-9590
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> For more information about origin of this issue see JBEAP-13856.
> Auto-create-jms-queues and auto-delete-jms-queues enable or disable automatic creation or deletion of JMS queues when they are requested or when they are not used anymore.
> In EAP 7.1 the features are disabled by default and they are Technical previews.
> In EAP 7.2 the features cannot be disabled via mentioned management attributes and thus they are always enabled. The ?cannot be? in previous sentence means that the configuration has no effect.
> *Customer impact:* Behavior of messaging broker was changed in case of automatic creation and deletion JMS destinations.



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


From issues at jboss.org  Fri Dec  1 09:13:01 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 1 Dec 2017 09:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9590)
 auto-[create|delete]-jms-queues are not supported in Artemis 2.4
In-Reply-To: <JIRA.12723095.1512137513000@Atlassian.JIRA>
References: <JIRA.12723095.1512137513000@Atlassian.JIRA>
	<JIRA.12723095.1512137513000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723095.1512137513000.70407.1512137581644@Atlassian.JIRA>


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

Jeff Mesnil updated WFLY-9590:
------------------------------
    Summary: auto-[create|delete]-jms-queues are not supported in Artemis 2.4  (was: Auto-[create|delete]-jms-queues cannot be disabled)


> auto-[create|delete]-jms-queues are not supported in Artemis 2.4
> ----------------------------------------------------------------
>
>                 Key: WFLY-9590
>                 URL: https://issues.jboss.org/browse/WFLY-9590
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> For more information about origin of this issue see JBEAP-13856.
> Auto-create-jms-queues and auto-delete-jms-queues enable or disable automatic creation or deletion of JMS queues when they are requested or when they are not used anymore.
> In EAP 7.1 the features are disabled by default and they are Technical previews.
> In EAP 7.2 the features cannot be disabled via mentioned management attributes and thus they are always enabled. The ?cannot be? in previous sentence means that the configuration has no effect.
> *Customer impact:* Behavior of messaging broker was changed in case of automatic creation and deletion JMS destinations.



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


From issues at jboss.org  Fri Dec  1 10:42:00 2017
From: issues at jboss.org (Ivo Bek (JIRA))
Date: Fri, 1 Dec 2017 10:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2160) Enhance UI in Test
	Scenarios Editor
In-Reply-To: <JIRA.12723168.1512142860000@Atlassian.JIRA>
References: <JIRA.12723168.1512142860000@Atlassian.JIRA>
	<JIRA.12723168.1512142860619@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723168.1512142860000.71275.1512142920267@Atlassian.JIRA>

Ivo Bek created DROOLS-2160:
-------------------------------

             Summary: 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: Toni Rikkola
         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  Fri Dec  1 10:42:00 2017
From: issues at jboss.org (Ivo Bek (JIRA))
Date: Fri, 1 Dec 2017 10:42: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.71279.1512142920422@Atlassian.JIRA>


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

Ivo Bek commented on DROOLS-2160:
---------------------------------

+ [~jomarko]

> 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: Toni Rikkola
>         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  Fri Dec  1 11:19:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Fri, 1 Dec 2017 11:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1597) Implement profile for
 integration with Signavio's DMN modeler
In-Reply-To: <JIRA.12695747.1496446212000@Atlassian.JIRA>
References: <JIRA.12695747.1496446212000@Atlassian.JIRA>
	<JIRA.12695747.1496446212000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12695747.1496446212000.71512.1512145140058@Atlassian.JIRA>


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

Edson Tirelli updated DROOLS-1597:
----------------------------------
    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  (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)


> Implement profile for integration with Signavio's DMN modeler
> -------------------------------------------------------------
>
>                 Key: DROOLS-1597
>                 URL: https://issues.jboss.org/browse/DROOLS-1597
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>    Affects Versions: 7.1.0.Beta2
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 7.5.0.Final
>
>
> Signavio implements a number of extensions to the DMN standard. As they are a Red Hat partner, we will need to implement a profile in the runtime engine that enables and supports those extensions.
> A short list of extensions is as follows. Details will be added to individual tickets:
> * Support additional FEEL functions and alternate names for existing functions
> * Support the Multi Instance Decision node
> * Support character '?' for interpolation of values in a DT cell
> * Support constraints on List inputs in DT cells
> * Support model composition through BKMs



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

From issues at jboss.org  Fri Dec  1 23:10:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Fri, 1 Dec 2017 23:10:00 -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.1512187777356@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723195.1512187777000.72157.1512187800186@Atlassian.JIRA>

Edson Tirelli created DROOLS-2161:
-------------------------------------

             Summary: 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: Edson Tirelli
         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  Sat Dec  2 09:00:00 2017
From: issues at jboss.org (Marcus Handte (JIRA))
Date: Sat, 2 Dec 2017 09:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1658) EJBAccessException for
 methods with @PermitAll but using arrays in parameters
In-Reply-To: <JIRA.12495941.1373301132000@Atlassian.JIRA>
References: <JIRA.12495941.1373301132000@Atlassian.JIRA>
	<JIRA.12495941.1373301132000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495941.1373301132000.72303.1512223200322@Atlassian.JIRA>


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

Marcus Handte commented on WFLY-1658:
-------------------------------------

Unfortunately, I have to report that this bug seems to be present again in Wildfly-10.1.0.Final.

After replacing an array parameter with a list of the same type on a session bean, I am able to use a method that did not work previously in an arquillian test.

> EJBAccessException for methods with @PermitAll but using arrays in parameters
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1658
>                 URL: https://issues.jboss.org/browse/WFLY-1658
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha2
>         Environment: 8.0.0.Alpha2 / Oracle JDK 7
>            Reporter: Christophe Fillot
>            Assignee: jaikiran pai
>              Labels: ejb, security-domain
>             Fix For: 8.0.0.Alpha3
>
>
> Calling an EJB method containing an array in parameters throws EJBAccessException, even if the method has @PermitAll annotation.



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

From issues at jboss.org  Sun Dec  3 08:48:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Sun, 3 Dec 2017 08:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1658) EJBAccessException for
 methods with @PermitAll but using arrays in parameters
In-Reply-To: <JIRA.12495941.1373301132000@Atlassian.JIRA>
References: <JIRA.12495941.1373301132000@Atlassian.JIRA>
	<JIRA.12495941.1373301132000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495941.1373301132000.72387.1512308880276@Atlassian.JIRA>


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

David Lloyd commented on WFLY-1658:
-----------------------------------

Could you please open a new JIRA and link it to this one?

> EJBAccessException for methods with @PermitAll but using arrays in parameters
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1658
>                 URL: https://issues.jboss.org/browse/WFLY-1658
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha2
>         Environment: 8.0.0.Alpha2 / Oracle JDK 7
>            Reporter: Christophe Fillot
>            Assignee: jaikiran pai
>              Labels: ejb, security-domain
>             Fix For: 8.0.0.Alpha3
>
>
> Calling an EJB method containing an array in parameters throws EJBAccessException, even if the method has @PermitAll annotation.



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

From issues at jboss.org  Sun Dec  3 14:21:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sun, 3 Dec 2017 14:21: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.72402.1512328860285@Atlassian.JIRA>


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

Jan Kalina edited comment on ELY-283 at 12/3/17 2:20 PM:
---------------------------------------------------------

Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*
* To start: {code}GSSPROXY_BEHAVIOR=REMOTE_FIRST GSS_USE_PROXY=1 JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.jgss.lib=/usr/lib64/libgssapi_krb5.so.2.2 -Dsun.security.jgss.native=true -Dsun.security.nativegss.debug=true -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true" bin/standalone.sh{code}


was (Author: honza889):
Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*

> 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
>
>
> 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  Sun Dec  3 14:36:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sun, 3 Dec 2017 14:36: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.72405.1512329760116@Atlassian.JIRA>


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

Jan Kalina edited comment on ELY-283 at 12/3/17 2:35 PM:
---------------------------------------------------------

Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*
* currently Elytron initialize LoginContext/Krb5LoginModule even if native provider should be used - should be made optional for future, but for now there is need to provide keystore with given credential to continue (obtained credential should be ignored by GSSManager if correctly set)
* To start: {code}GSSPROXY_BEHAVIOR=REMOTE_FIRST GSS_USE_PROXY=1 JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.jgss.lib=/usr/lib64/libgssapi_krb5.so.2.2 -Dsun.security.jgss.native=true -Dsun.security.nativegss.debug=true -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true" bin/standalone.sh{code}


was (Author: honza889):
Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*
* To start: {code}GSSPROXY_BEHAVIOR=REMOTE_FIRST GSS_USE_PROXY=1 JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.jgss.lib=/usr/lib64/libgssapi_krb5.so.2.2 -Dsun.security.jgss.native=true -Dsun.security.nativegss.debug=true -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true" bin/standalone.sh{code}

> 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
>
>
> 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  Mon Dec  4 02:40:00 2017
From: issues at jboss.org (Boris Sh (JIRA))
Date: Mon, 4 Dec 2017 02:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2239) AUTH + ASYM_ENCRYPT causes
 problem with re-joining cluster (MERGE)
In-Reply-To: <JIRA.12723237.1512373184000@Atlassian.JIRA>
References: <JIRA.12723237.1512373184000@Atlassian.JIRA>
	<JIRA.12723237.1512373184876@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723237.1512373184000.72716.1512373200141@Atlassian.JIRA>

Boris Sh created JGRP-2239:
------------------------------

             Summary: AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)
                 Key: JGRP-2239
                 URL: https://issues.jboss.org/browse/JGRP-2239
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 4.0.6
         Environment: Infinispan 9.1.1 + JGroups 4.0.6.Final + Vert.x 3.5.0
            Reporter: Boris Sh
            Assignee: Bela Ban


Hello,
I am using the following configuration:

{code:java}
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
	<UDP />
	<PING />
	<MERGE3 />
	<FD />
	<VERIFY_SUSPECT />

	<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
		sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
		asym_algorithm="RSA" />

	<pbcast.NAKACK2 />
	<UNICAST3 />
	<pbcast.STABLE />
	<FRAG2 />
	<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
		keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
		cipher_type="RSA" />

	<pbcast.GMS />
</config>
{code}

I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.

Initially, when these nodes join the cluster, everything is fine.
The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):


{code:java}
org.jgroups.protocols.FD up
WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
 org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-36734
org.jgroups.protocols.Encrypt handleEncryptedMessage
{code}

so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".

In cluster coordinator logs I see the following:

{code:java}
INFO: ISPN100000: Node node-26978 joined the cluster
****
WARN: node-27291: unrecognized cipher; discarding message from node-26978
org.jgroups.logging.Slf4jLogImpl error
ERROR: key requester  node-26978 is not in current view [***]; ignoring key request
org.jgroups.logging.Slf4jLogImpl warn
WARN: node-27291: unrecognized cipher; discarding message from node-26978

INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]

{code}


My understanding of what has happened:
For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and don't fully understand why this happens.

How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, and the key doesn't change.

Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.

So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.



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

From issues at jboss.org  Mon Dec  4 02:46:00 2017
From: issues at jboss.org (Boris Sh (JIRA))
Date: Mon, 4 Dec 2017 02:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2239) AUTH + ASYM_ENCRYPT causes
 problem with re-joining cluster (MERGE)
In-Reply-To: <JIRA.12723237.1512373185000@Atlassian.JIRA>
References: <JIRA.12723237.1512373185000@Atlassian.JIRA>
	<JIRA.12723237.1512373185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723237.1512373185000.72744.1512373560269@Atlassian.JIRA>


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

Boris Sh updated JGRP-2239:
---------------------------
    Description: 
Hello,
I am using the following configuration:

{code:java}
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
	<UDP />
	<PING />
	<MERGE3 />
	<FD />
	<VERIFY_SUSPECT />

	<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
		sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
		asym_algorithm="RSA" />

	<pbcast.NAKACK2 />
	<UNICAST3 />
	<pbcast.STABLE />
	<FRAG2 />
	<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
		keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
		cipher_type="RSA" />

	<pbcast.GMS />
</config>
{code}

I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.

Initially, when these nodes join the cluster, everything is fine.
The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):


{code:java}
org.jgroups.protocols.FD up
WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
 org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-36734
org.jgroups.protocols.Encrypt handleEncryptedMessage
{code}

so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".

In cluster coordinator logs I see the following:

{code:java}
INFO: ISPN100000: Node node-26978 joined the cluster
****
WARN: node-27291: unrecognized cipher; discarding message from node-26978
org.jgroups.logging.Slf4jLogImpl error
ERROR: key requester  node-26978 is not in current view [***]; ignoring key request
org.jgroups.logging.Slf4jLogImpl warn
WARN: node-27291: unrecognized cipher; discarding message from node-26978

INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]

{code}


My understanding of what has happened:
For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens.

How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, and the key doesn't change.

Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.

So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.

  was:
Hello,
I am using the following configuration:

{code:java}
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
	<UDP />
	<PING />
	<MERGE3 />
	<FD />
	<VERIFY_SUSPECT />

	<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
		sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
		asym_algorithm="RSA" />

	<pbcast.NAKACK2 />
	<UNICAST3 />
	<pbcast.STABLE />
	<FRAG2 />
	<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
		keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
		cipher_type="RSA" />

	<pbcast.GMS />
</config>
{code}

I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.

Initially, when these nodes join the cluster, everything is fine.
The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):


{code:java}
org.jgroups.protocols.FD up
WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
 org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-36734
org.jgroups.protocols.Encrypt handleEncryptedMessage
{code}

so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".

In cluster coordinator logs I see the following:

{code:java}
INFO: ISPN100000: Node node-26978 joined the cluster
****
WARN: node-27291: unrecognized cipher; discarding message from node-26978
org.jgroups.logging.Slf4jLogImpl error
ERROR: key requester  node-26978 is not in current view [***]; ignoring key request
org.jgroups.logging.Slf4jLogImpl warn
WARN: node-27291: unrecognized cipher; discarding message from node-26978

INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]

{code}


My understanding of what has happened:
For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and don't fully understand why this happens.

How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, and the key doesn't change.

Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.

So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.



> AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)
> ------------------------------------------------------------------
>
>                 Key: JGRP-2239
>                 URL: https://issues.jboss.org/browse/JGRP-2239
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.6
>         Environment: Infinispan 9.1.1 + JGroups 4.0.6.Final + Vert.x 3.5.0
>            Reporter: Boris Sh
>            Assignee: Bela Ban
>
> Hello,
> I am using the following configuration:
> {code:java}
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> 	<UDP />
> 	<PING />
> 	<MERGE3 />
> 	<FD />
> 	<VERIFY_SUSPECT />
> 	<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
> 		sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
> 		asym_algorithm="RSA" />
> 	<pbcast.NAKACK2 />
> 	<UNICAST3 />
> 	<pbcast.STABLE />
> 	<FRAG2 />
> 	<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
> 		keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
> 		cipher_type="RSA" />
> 	<pbcast.GMS />
> </config>
> {code}
> I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.
> Initially, when these nodes join the cluster, everything is fine.
> The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):
> {code:java}
> org.jgroups.protocols.FD up
> WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
>  org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-36734
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> {code}
> so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".
> In cluster coordinator logs I see the following:
> {code:java}
> INFO: ISPN100000: Node node-26978 joined the cluster
> ****
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> org.jgroups.logging.Slf4jLogImpl error
> ERROR: key requester  node-26978 is not in current view [***]; ignoring key request
> org.jgroups.logging.Slf4jLogImpl warn
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]
> {code}
> My understanding of what has happened:
> For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens.
> How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, and the key doesn't change.
> Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.
> So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.



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

From issues at jboss.org  Mon Dec  4 02:47:00 2017
From: issues at jboss.org (Boris Sh (JIRA))
Date: Mon, 4 Dec 2017 02:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2239) AUTH + ASYM_ENCRYPT causes
 problem with re-joining cluster (MERGE)
In-Reply-To: <JIRA.12723237.1512373185000@Atlassian.JIRA>
References: <JIRA.12723237.1512373185000@Atlassian.JIRA>
	<JIRA.12723237.1512373185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723237.1512373185000.72756.1512373620605@Atlassian.JIRA>


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

Boris Sh updated JGRP-2239:
---------------------------
    Description: 
Hello,
I am using the following configuration:

{code:java}
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
	<UDP />
	<PING />
	<MERGE3 />
	<FD />
	<VERIFY_SUSPECT />

	<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
		sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
		asym_algorithm="RSA" />

	<pbcast.NAKACK2 />
	<UNICAST3 />
	<pbcast.STABLE />
	<FRAG2 />
	<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
		keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
		cipher_type="RSA" />

	<pbcast.GMS />
</config>
{code}

I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.

Initially, when these nodes join the cluster, everything is fine.
The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):


{code:java}
org.jgroups.protocols.FD up
WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
 org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-36734
org.jgroups.protocols.Encrypt handleEncryptedMessage
{code}

so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".

In cluster coordinator logs I see the following:

{code:java}
INFO: ISPN100000: Node node-26978 joined the cluster
****
WARN: node-27291: unrecognized cipher; discarding message from node-26978
org.jgroups.logging.Slf4jLogImpl error
ERROR: key requester  node-26978 is not in current view [***]; ignoring key request
org.jgroups.logging.Slf4jLogImpl warn
WARN: node-27291: unrecognized cipher; discarding message from node-26978

INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]

{code}


My understanding of what has happened:
For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens.

How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, as the key doesn't change.

Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.

So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.

  was:
Hello,
I am using the following configuration:

{code:java}
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
	<UDP />
	<PING />
	<MERGE3 />
	<FD />
	<VERIFY_SUSPECT />

	<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
		sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
		asym_algorithm="RSA" />

	<pbcast.NAKACK2 />
	<UNICAST3 />
	<pbcast.STABLE />
	<FRAG2 />
	<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
		keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
		cipher_type="RSA" />

	<pbcast.GMS />
</config>
{code}

I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.

Initially, when these nodes join the cluster, everything is fine.
The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):


{code:java}
org.jgroups.protocols.FD up
WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-27291
 org.jgroups.protocols.Encrypt handleEncryptedMessage
WARNING: node-26978: unrecognized cipher; discarding message from node-36734
org.jgroups.protocols.Encrypt handleEncryptedMessage
{code}

so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".

In cluster coordinator logs I see the following:

{code:java}
INFO: ISPN100000: Node node-26978 joined the cluster
****
WARN: node-27291: unrecognized cipher; discarding message from node-26978
org.jgroups.logging.Slf4jLogImpl error
ERROR: key requester  node-26978 is not in current view [***]; ignoring key request
org.jgroups.logging.Slf4jLogImpl warn
WARN: node-27291: unrecognized cipher; discarding message from node-26978

INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]

{code}


My understanding of what has happened:
For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens.

How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, and the key doesn't change.

Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.

So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.



> AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)
> ------------------------------------------------------------------
>
>                 Key: JGRP-2239
>                 URL: https://issues.jboss.org/browse/JGRP-2239
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.6
>         Environment: Infinispan 9.1.1 + JGroups 4.0.6.Final + Vert.x 3.5.0
>            Reporter: Boris Sh
>            Assignee: Bela Ban
>
> Hello,
> I am using the following configuration:
> {code:java}
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> 	<UDP />
> 	<PING />
> 	<MERGE3 />
> 	<FD />
> 	<VERIFY_SUSPECT />
> 	<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
> 		sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
> 		asym_algorithm="RSA" />
> 	<pbcast.NAKACK2 />
> 	<UNICAST3 />
> 	<pbcast.STABLE />
> 	<FRAG2 />
> 	<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
> 		keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
> 		cipher_type="RSA" />
> 	<pbcast.GMS />
> </config>
> {code}
> I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.
> Initially, when these nodes join the cluster, everything is fine.
> The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):
> {code:java}
> org.jgroups.protocols.FD up
> WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
>  org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-36734
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> {code}
> so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".
> In cluster coordinator logs I see the following:
> {code:java}
> INFO: ISPN100000: Node node-26978 joined the cluster
> ****
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> org.jgroups.logging.Slf4jLogImpl error
> ERROR: key requester  node-26978 is not in current view [***]; ignoring key request
> org.jgroups.logging.Slf4jLogImpl warn
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]
> {code}
> My understanding of what has happened:
> For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens.
> How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, as the key doesn't change.
> Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.
> So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.



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

From issues at jboss.org  Mon Dec  4 03:32:00 2017
From: issues at jboss.org (Nuno Godinho de Matos (JIRA))
Date: Mon, 4 Dec 2017 03:32: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.72918.1512376320083@Atlassian.JIRA>


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

Nuno Godinho de Matos commented on WFLY-9542:
---------------------------------------------

Would it be possible to get a bit of direction on where patching should ideally applied to tackle this issue?

Many thanks for your understanding,
Kindest regards.

> 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  Mon Dec  4 04:18:00 2017
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Mon, 4 Dec 2017 04:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9587) Investigate and introduce
 capabilities for the transactional subsytems transations/xts/rts
In-Reply-To: <JIRA.12722888.1512034178000@Atlassian.JIRA>
References: <JIRA.12722888.1512034178000@Atlassian.JIRA>
	<JIRA.12722888.1512034178000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722888.1512034178000.73055.1512379080374@Atlassian.JIRA>


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

Ondra Chaloupka commented on WFLY-9587:
---------------------------------------

[~brian.stansberry]: Hi Brian,

thanks a lot! That's a great summary and guideline for me to work with. I hope as I will be able I will get to start with looking into it. This issue came from a discussion on our f2f meeting and it's still a long-term goal. I expect first to check out the dependency labyrinth represented by issue WFLY-9588.

To react at the last part of the 3) - I wonder why the expression is permitted on jts element. Was not that rather just a mistake? Using expressions for jts sounds pretty as extreme corner case and breaking compatibility not sounding so bad (at least to me).
.

> Investigate and introduce capabilities for the transactional subsytems transations/xts/rts
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9587
>                 URL: https://issues.jboss.org/browse/WFLY-9587
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Transactions, XTS
>    Affects Versions: 11.0.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> The notion of capability is not introduced to the transactional system. The WFLY integration expecting subsystem providing it. The transaction subsystems should support so.
> https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities



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

From issues at jboss.org  Mon Dec  4 04:20:00 2017
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Mon, 4 Dec 2017 04:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9588) Investigate on splitting as
 transaction module to not be gathering all dependencies
In-Reply-To: <JIRA.12722920.1512043192000@Atlassian.JIRA>
References: <JIRA.12722920.1512043192000@Atlassian.JIRA>
	<JIRA.12722920.1512043192000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722920.1512043192000.73071.1512379200440@Atlassian.JIRA>


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

Ondra Chaloupka commented on WFLY-9588:
---------------------------------------

not sure if directly block WFLY-9455 but making easier more granular dependency graph could help a lot in solving it

> Investigate on splitting as transaction module to not be gathering all dependencies
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-9588
>                 URL: https://issues.jboss.org/browse/WFLY-9588
>             Project: WildFly
>          Issue Type: Task
>          Components: Transactions
>    Affects Versions: 11.0.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>         Attachments: eap71-txn-dependencies.jpg
>
>
> Current org.jboss.as.transaction module is heavy lifting and has many dependencies and lot of work competencies. E.g. org.jboss.jts module depends on that too.
> It should be investigated how to disentangle all the dependencies.
> Plus this could be beneficiary for WildFly Swarm if we are able to split the dependency chains, maybe not using one big jar in the transaction module but provide more granularity. Needs to be investigated.
> See attached image for a view of dependencies.



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

From issues at jboss.org  Mon Dec  4 04:20:00 2017
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Mon, 4 Dec 2017 04:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9588) Investigate on splitting as
 transaction module to not be gathering all dependencies
In-Reply-To: <JIRA.12722920.1512043192000@Atlassian.JIRA>
References: <JIRA.12722920.1512043192000@Atlassian.JIRA>
	<JIRA.12722920.1512043192000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722920.1512043192000.73074.1512379200545@Atlassian.JIRA>


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

Ondra Chaloupka edited comment on WFLY-9588 at 12/4/17 4:19 AM:
----------------------------------------------------------------

not sure if directly block WFLY-9455 but making easier more granular dependency graph could help a lot in solving it


was (Author: ochaloup):
not sure if directly block WFLY-9455 but making easier more granular dependency graph could help a lot in solving it

> Investigate on splitting as transaction module to not be gathering all dependencies
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-9588
>                 URL: https://issues.jboss.org/browse/WFLY-9588
>             Project: WildFly
>          Issue Type: Task
>          Components: Transactions
>    Affects Versions: 11.0.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>         Attachments: eap71-txn-dependencies.jpg
>
>
> Current org.jboss.as.transaction module is heavy lifting and has many dependencies and lot of work competencies. E.g. org.jboss.jts module depends on that too.
> It should be investigated how to disentangle all the dependencies.
> Plus this could be beneficiary for WildFly Swarm if we are able to split the dependency chains, maybe not using one big jar in the transaction module but provide more granularity. Needs to be investigated.
> See attached image for a view of dependencies.



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

From issues at jboss.org  Mon Dec  4 04:24:00 2017
From: issues at jboss.org (Boris Sh (JIRA))
Date: Mon, 4 Dec 2017 04:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2239) AUTH + ASYM_ENCRYPT causes
 problem with re-joining cluster (MERGE)
In-Reply-To: <JIRA.12723237.1512373185000@Atlassian.JIRA>
References: <JIRA.12723237.1512373185000@Atlassian.JIRA>
	<JIRA.12723237.1512373185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723237.1512373185000.73092.1512379440137@Atlassian.JIRA>


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

Boris Sh updated JGRP-2239:
---------------------------
    Steps to Reproduce: 
It was not easy for me to reproduce this problem on linux prod server, so what I did on my Windows dev machine:

1. Deployed 3 nodes (Not needed to have all 7 for test, 3 is enough. And I couldn't reproduce the issue on 2 nodes in cluster).
2. Started "CPU Stress" util with maximum thread priorities and activity for all CPU cores on my PC for 3-5 minutes.
3. Stopped "CPU Stress".
4. See the problem in logs: one node has left the cluster, and after "merge" request cluster became look a bit strange - now has 2 subgroups. And kicked node can't communicate with any other node, log is fulfilled with error messages like "unrecognized cipher".

  was:
It was not easy for me to reproduce with problem on linux prod server, so what I did on my Windows dev machine:

1. Deployed 3 nodes (Not needed to have all 7 for test, 3 is enough. And I couldn't reproduce the issue on 2 nodes in cluster).
2. Started "CPU Stress" util with maximum thread priorities and activity for all CPU cores on my PC for 3-5 minutes.
3. Stopped "CPU Stress".
4. See the problem in logs: one node has left the cluster, and after "merge" request cluster became look a bit strange - now has 2 subgroups. And kicked node can't communicate with any other node, log is fulfilled with error messages like "unrecognized cipher".



> AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)
> ------------------------------------------------------------------
>
>                 Key: JGRP-2239
>                 URL: https://issues.jboss.org/browse/JGRP-2239
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.6
>         Environment: Infinispan 9.1.1 + JGroups 4.0.6.Final + Vert.x 3.5.0
>            Reporter: Boris Sh
>            Assignee: Bela Ban
>
> Hello,
> I am using the following configuration:
> {code:java}
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> 	<UDP />
> 	<PING />
> 	<MERGE3 />
> 	<FD />
> 	<VERIFY_SUSPECT />
> 	<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
> 		sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
> 		asym_algorithm="RSA" />
> 	<pbcast.NAKACK2 />
> 	<UNICAST3 />
> 	<pbcast.STABLE />
> 	<FRAG2 />
> 	<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
> 		keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
> 		cipher_type="RSA" />
> 	<pbcast.GMS />
> </config>
> {code}
> I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.
> Initially, when these nodes join the cluster, everything is fine.
> The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):
> {code:java}
> org.jgroups.protocols.FD up
> WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
>  org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-36734
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> {code}
> so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".
> In cluster coordinator logs I see the following:
> {code:java}
> INFO: ISPN100000: Node node-26978 joined the cluster
> ****
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> org.jgroups.logging.Slf4jLogImpl error
> ERROR: key requester  node-26978 is not in current view [***]; ignoring key request
> org.jgroups.logging.Slf4jLogImpl warn
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]
> {code}
> My understanding of what has happened:
> For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens.
> How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, as the key doesn't change.
> Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.
> So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.



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

From issues at jboss.org  Mon Dec  4 04:25:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 4 Dec 2017 04:25: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.73095.1512379500235@Atlassian.JIRA>


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

Jozef Marko updated DROOLS-2160:
--------------------------------
    Tester: Jozef Marko


> 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: Toni Rikkola
>         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  Mon Dec  4 04:31:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 4 Dec 2017 04:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1457) Unable to run testsuite using
 mvn surefire:test
In-Reply-To: <JIRA.12723250.1512379856000@Atlassian.JIRA>
References: <JIRA.12723250.1512379856000@Atlassian.JIRA>
	<JIRA.12723250.1512379856598@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723250.1512379856000.73110.1512379860289@Atlassian.JIRA>

Martin Choma created ELY-1457:
---------------------------------

             Summary: Unable to run testsuite using mvn surefire:test
                 Key: ELY-1457
                 URL: https://issues.jboss.org/browse/ELY-1457
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Testsuite, Utils
    Affects Versions: 1.2.0.Beta10
            Reporter: Martin Choma
            Priority: Minor


{noformat}
mvn clean install -DskipTests
mvn surefire:test -fae -Dmaven.test.failure.ignore=true

[WARNING] Corrupted stdin stream in forked JVM 1. See the dump file /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire-reports/2017-11-30T17-02-48_325-jvmRun1.dumpstream

ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
Command was /bin/sh -c cd /home/mchoma/workspace/git-repositories/wildfly-elytron && /usr/java/jdk1.8.0_131/jre/bin/java '-javaagent:${org.jmockit:jmockit:jar}' -jar /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire/surefirebooter575191532113315054.jar /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire 2017-11-30T17-02-48_325-jvmRun1 surefire4127140177271714029tmp surefire_06835135917194901533tmp
Error occurred in starting fork, check output in log
Process Exit Code: 1
{noformat}

"mvn test" works just fine.

"mvn surefire:test" used to be necessary for running testsuite with IBM JDK, as TS was not compilable with IBM JDK (this is not true anymore). So TS was build with Oracle JDK and run with IBM JDK. 
 
"mvn surefire:test" used to work back in July.



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

From issues at jboss.org  Mon Dec  4 04:32:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 4 Dec 2017 04:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1457) Unable to run testsuite using
 mvn surefire:test
In-Reply-To: <JIRA.12723250.1512379857000@Atlassian.JIRA>
References: <JIRA.12723250.1512379857000@Atlassian.JIRA>
	<JIRA.12723250.1512379857000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723250.1512379857000.73114.1512379920298@Atlassian.JIRA>


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

Martin Choma updated ELY-1457:
------------------------------
    Description: 
{noformat}
mvn clean install -DskipTests
mvn surefire:test -fae -Dmaven.test.failure.ignore=true

[WARNING] Corrupted stdin stream in forked JVM 1. See the dump file /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire-reports/2017-11-30T17-02-48_325-jvmRun1.dumpstream

ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
Command was /bin/sh -c cd /home/mchoma/workspace/git-repositories/wildfly-elytron && /usr/java/jdk1.8.0_131/jre/bin/java '-javaagent:${org.jmockit:jmockit:jar}' -jar /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire/surefirebooter575191532113315054.jar /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire 2017-11-30T17-02-48_325-jvmRun1 surefire4127140177271714029tmp surefire_06835135917194901533tmp
Error occurred in starting fork, check output in log
Process Exit Code: 1
{noformat}

*  "mvn test" works just fine.
*  "mvn surefire:test" used to be necessary for running testsuite with IBM JDK, as TS was not compilable with IBM JDK (this is not true anymore). So TS was build with Oracle JDK and run with IBM JDK. 
*  "mvn surefire:test" used to work back in July.

  was:
{noformat}
mvn clean install -DskipTests
mvn surefire:test -fae -Dmaven.test.failure.ignore=true

[WARNING] Corrupted stdin stream in forked JVM 1. See the dump file /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire-reports/2017-11-30T17-02-48_325-jvmRun1.dumpstream

ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
Command was /bin/sh -c cd /home/mchoma/workspace/git-repositories/wildfly-elytron && /usr/java/jdk1.8.0_131/jre/bin/java '-javaagent:${org.jmockit:jmockit:jar}' -jar /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire/surefirebooter575191532113315054.jar /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire 2017-11-30T17-02-48_325-jvmRun1 surefire4127140177271714029tmp surefire_06835135917194901533tmp
Error occurred in starting fork, check output in log
Process Exit Code: 1
{noformat}

"mvn test" works just fine.

"mvn surefire:test" used to be necessary for running testsuite with IBM JDK, as TS was not compilable with IBM JDK (this is not true anymore). So TS was build with Oracle JDK and run with IBM JDK. 
 
"mvn surefire:test" used to work back in July.



> Unable to run testsuite using mvn surefire:test
> -----------------------------------------------
>
>                 Key: ELY-1457
>                 URL: https://issues.jboss.org/browse/ELY-1457
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite, Utils
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Priority: Minor
>
> {noformat}
> mvn clean install -DskipTests
> mvn surefire:test -fae -Dmaven.test.failure.ignore=true
> [WARNING] Corrupted stdin stream in forked JVM 1. See the dump file /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire-reports/2017-11-30T17-02-48_325-jvmRun1.dumpstream
> ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
> Command was /bin/sh -c cd /home/mchoma/workspace/git-repositories/wildfly-elytron && /usr/java/jdk1.8.0_131/jre/bin/java '-javaagent:${org.jmockit:jmockit:jar}' -jar /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire/surefirebooter575191532113315054.jar /home/mchoma/workspace/git-repositories/wildfly-elytron/target/surefire 2017-11-30T17-02-48_325-jvmRun1 surefire4127140177271714029tmp surefire_06835135917194901533tmp
> Error occurred in starting fork, check output in log
> Process Exit Code: 1
> {noformat}
> *  "mvn test" works just fine.
> *  "mvn surefire:test" used to be necessary for running testsuite with IBM JDK, as TS was not compilable with IBM JDK (this is not true anymore). So TS was build with Oracle JDK and run with IBM JDK. 
> *  "mvn surefire:test" used to work back in July.



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

From issues at jboss.org  Mon Dec  4 04:42:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 4 Dec 2017 04:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1458)
 SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues
 fails on IBM JDK
In-Reply-To: <JIRA.12723253.1512380463000@Atlassian.JIRA>
References: <JIRA.12723253.1512380463000@Atlassian.JIRA>
	<JIRA.12723253.1512380463889@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723253.1512380463000.73165.1512380520176@Atlassian.JIRA>

Martin Choma created ELY-1458:
---------------------------------

             Summary: SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues fails on IBM JDK
                 Key: ELY-1458
                 URL: https://issues.jboss.org/browse/ELY-1458
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Certificate Authority
    Affects Versions: 1.2.0.Beta10
            Reporter: Martin Choma


With IBM java
{noformat}
java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170516_348050 (JIT enabled, AOT enabled)
J9VM - R28_20170516_1905_B348050
JIT  - tr.r14.java_20170516_348050
GC   - R28_20170516_1905_B348050_CMPRSS
J9CL - 20170516_348050)
JCL - 20170516_01 based on Oracle jdk8u131-b11
{noformat}

run test
{noformat}
 mvn test -Dtest=SelfSignedX509CertificateAndSigningKeyTest

[INFO] Running org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
[ERROR] Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.372 s <<< FAILURE! - in org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
[ERROR] testSelfSignedCertificateWithStringExtensionValues(org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest)  Time elapsed: 0.274 s  <<< FAILURE!
java.lang.AssertionError
	at org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues(SelfSignedX509CertificateAndSigningKeyTest.java:197)

{noformat}

This is test line failing
{code:java|title=SelfSignedX509CertificateAndSigningKeyTest.java}
        byte[] authorityInfoAccessExtension = certificate.getExtensionValue(X500.OID_PE_AUTHORITY_INFO_ACCESS);
        assertNotNull(authorityInfoAccessExtension);
{code}



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

From issues at jboss.org  Mon Dec  4 04:50:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 4 Dec 2017 04:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1458)
 SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues
 fails on IBM JDK
In-Reply-To: <JIRA.12723253.1512380464000@Atlassian.JIRA>
References: <JIRA.12723253.1512380464000@Atlassian.JIRA>
	<JIRA.12723253.1512380464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723253.1512380464000.73206.1512381000101@Atlassian.JIRA>


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

Martin Choma commented on ELY-1458:
-----------------------------------

With debugging I can see test is failing on searching OID 1.3.6.1.5.5.7.1.1 which is located in Unparseable certificate extensions
{noformat}
[
[
  Version: V3
  Subject: CN=bob smith, OU=jboss, O=red hat, L=raleigh, ST=north carolina, C=us
  Signature Algorithm: SHA256withDSA, OID = 2.16.840.1.101.3.4.3.2

  Key:  IBMJCE DSA Public Key:
10389539464412903556924870926977456600328661145126110914220364993646327182827897057810681641838672622783970775653085652971888667064482151030822018565974084164812785937167067899265071806883189425808652614041346698609430428488623420867004775841831737139272403718817301879754589951077983369859385368318809992517855682694872534538862937538545227595881495646173926384613674206105836908073825850547714481997228126103022280543137613384164844604733917034425561783854025917174233571273088420726961501571798407502539168274663967684401560564643528658155154341567883345191932615679686743952146121930966280400203143164167037724051

  Validity: [From: Mon Dec 04 10:42:29 CET 2017,
               To: Sat Jan 01 00:59:59 CET 10000]
  Issuer: CN=bob smith, OU=jboss, O=red hat, L=raleigh, ST=north carolina, C=us
  SerialNumber: [1965736310424294143]

Certificate Extensions: 7
[1]: ObjectId: 1.3.6.1.5.5.7.1.11 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 38 30 36 30 10 06 08  2b 06 01 05 05 07 30 03  .8060.........0.
0010: 87 04 0b 16 21 2c 30 22  06 08 2b 06 01 05 05 07  ......0.........
0020: 30 05 86 16 68 74 74 70  3a 2f 2f 61 6e 6f 74 68  0...http...anoth
0030: 65 72 2e 75 72 6c 2e 63  6f 6d                    er.url.com


[2]: ObjectId: 2.5.29.18 Criticality=false
IssuerAlternativeName [
[IPAddress: 10.20.30.40, URIName: http://some.url.com]]

[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_CertSign
  Crl_Sign
]

[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 4d cb ee b6 cf 01 78 b7  d3 5c 65 16 96 a2 3c 4b  M.....x...e....K
0010: e8 d8 5f a0                                        ....
]
]

[5]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2
]

[6]: ObjectId: 2.5.29.37 Criticality=false
ExtKeyUsage [
	1.3.6.1.5.5.7.3.2	1.3.6.1.5.5.7.3.8]

[7]: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
[RFC822Name: bobsmith at example.com, DNSName: bobsmith.example.com]]

Unparseable certificate extensions: 1
[1]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
0000: 30 3f 30 1c 06 08 2b 06  01 05 05 07 30 01 86 10  0.0.........0...
0010: 31 30 2e 32 30 2e 33 30  2e 34 30 3a 38 30 38 30  10.20.30.40.8080
0020: 30 1f 06 08 2b 06 01 05  05 07 30 02 82 13 69 73  0.........0...is
0030: 73 75 65 72 73 2e 65 78  61 6d 70 6c 65 2e 63 6f  suers.example.co
0040: 6d                                                 m

]
  Algorithm: [SHA256withDSA]
  Signature:
0000: 30 45 02 21 00 a8 4a dc  8b 0e a3 bd 55 7f 78 2a  0E....J.....U.x.
0010: 4e 68 17 b7 72 34 7d d0  77 c6 31 1e 00 ea f0 23  Nh..r4..w.1.....
0020: 06 a9 54 dd 7d 02 20 1b  19 b9 ef 4b 73 42 8b 4c  ..T........KsB.L
0030: d5 19 a7 1e 86 1c 44 60  24 2c dc b1 29 1a bc 89  ......D.........
0040: e9 92 01 b2 55 fd 90                               ....U..

]
{noformat}

> SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues fails on IBM JDK
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-1458
>                 URL: https://issues.jboss.org/browse/ELY-1458
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Certificate Authority
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>
> With IBM java
> {noformat}
> java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> {noformat}
> run test
> {noformat}
>  mvn test -Dtest=SelfSignedX509CertificateAndSigningKeyTest
> [INFO] Running org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.372 s <<< FAILURE! - in org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] testSelfSignedCertificateWithStringExtensionValues(org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest)  Time elapsed: 0.274 s  <<< FAILURE!
> java.lang.AssertionError
> 	at org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues(SelfSignedX509CertificateAndSigningKeyTest.java:197)
> {noformat}
> This is test line failing
> {code:java|title=SelfSignedX509CertificateAndSigningKeyTest.java}
>         byte[] authorityInfoAccessExtension = certificate.getExtensionValue(X500.OID_PE_AUTHORITY_INFO_ACCESS);
>         assertNotNull(authorityInfoAccessExtension);
> {code}



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

From issues at jboss.org  Mon Dec  4 04:51:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 4 Dec 2017 04:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1458)
 SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues
 fails on IBM JDK
In-Reply-To: <JIRA.12723253.1512380464000@Atlassian.JIRA>
References: <JIRA.12723253.1512380464000@Atlassian.JIRA>
	<JIRA.12723253.1512380464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723253.1512380464000.73209.1512381060069@Atlassian.JIRA>


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

Martin Choma edited comment on ELY-1458 at 12/4/17 4:50 AM:
------------------------------------------------------------

With debugging I can see test is failing on searching OID 1.3.6.1.5.5.7.1.1 which is located in "Unparseable certificate extensions". [~fjuma], could you have a look if this is real issue?

{noformat}
[
[
  Version: V3
  Subject: CN=bob smith, OU=jboss, O=red hat, L=raleigh, ST=north carolina, C=us
  Signature Algorithm: SHA256withDSA, OID = 2.16.840.1.101.3.4.3.2

  Key:  IBMJCE DSA Public Key:
10389539464412903556924870926977456600328661145126110914220364993646327182827897057810681641838672622783970775653085652971888667064482151030822018565974084164812785937167067899265071806883189425808652614041346698609430428488623420867004775841831737139272403718817301879754589951077983369859385368318809992517855682694872534538862937538545227595881495646173926384613674206105836908073825850547714481997228126103022280543137613384164844604733917034425561783854025917174233571273088420726961501571798407502539168274663967684401560564643528658155154341567883345191932615679686743952146121930966280400203143164167037724051

  Validity: [From: Mon Dec 04 10:42:29 CET 2017,
               To: Sat Jan 01 00:59:59 CET 10000]
  Issuer: CN=bob smith, OU=jboss, O=red hat, L=raleigh, ST=north carolina, C=us
  SerialNumber: [1965736310424294143]

Certificate Extensions: 7
[1]: ObjectId: 1.3.6.1.5.5.7.1.11 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 38 30 36 30 10 06 08  2b 06 01 05 05 07 30 03  .8060.........0.
0010: 87 04 0b 16 21 2c 30 22  06 08 2b 06 01 05 05 07  ......0.........
0020: 30 05 86 16 68 74 74 70  3a 2f 2f 61 6e 6f 74 68  0...http...anoth
0030: 65 72 2e 75 72 6c 2e 63  6f 6d                    er.url.com


[2]: ObjectId: 2.5.29.18 Criticality=false
IssuerAlternativeName [
[IPAddress: 10.20.30.40, URIName: http://some.url.com]]

[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_CertSign
  Crl_Sign
]

[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 4d cb ee b6 cf 01 78 b7  d3 5c 65 16 96 a2 3c 4b  M.....x...e....K
0010: e8 d8 5f a0                                        ....
]
]

[5]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2
]

[6]: ObjectId: 2.5.29.37 Criticality=false
ExtKeyUsage [
	1.3.6.1.5.5.7.3.2	1.3.6.1.5.5.7.3.8]

[7]: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
[RFC822Name: bobsmith at example.com, DNSName: bobsmith.example.com]]

Unparseable certificate extensions: 1
[1]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
0000: 30 3f 30 1c 06 08 2b 06  01 05 05 07 30 01 86 10  0.0.........0...
0010: 31 30 2e 32 30 2e 33 30  2e 34 30 3a 38 30 38 30  10.20.30.40.8080
0020: 30 1f 06 08 2b 06 01 05  05 07 30 02 82 13 69 73  0.........0...is
0030: 73 75 65 72 73 2e 65 78  61 6d 70 6c 65 2e 63 6f  suers.example.co
0040: 6d                                                 m

]
  Algorithm: [SHA256withDSA]
  Signature:
0000: 30 45 02 21 00 a8 4a dc  8b 0e a3 bd 55 7f 78 2a  0E....J.....U.x.
0010: 4e 68 17 b7 72 34 7d d0  77 c6 31 1e 00 ea f0 23  Nh..r4..w.1.....
0020: 06 a9 54 dd 7d 02 20 1b  19 b9 ef 4b 73 42 8b 4c  ..T........KsB.L
0030: d5 19 a7 1e 86 1c 44 60  24 2c dc b1 29 1a bc 89  ......D.........
0040: e9 92 01 b2 55 fd 90                               ....U..

]
{noformat}


was (Author: mchoma):
With debugging I can see test is failing on searching OID 1.3.6.1.5.5.7.1.1 which is located in Unparseable certificate extensions
{noformat}
[
[
  Version: V3
  Subject: CN=bob smith, OU=jboss, O=red hat, L=raleigh, ST=north carolina, C=us
  Signature Algorithm: SHA256withDSA, OID = 2.16.840.1.101.3.4.3.2

  Key:  IBMJCE DSA Public Key:
10389539464412903556924870926977456600328661145126110914220364993646327182827897057810681641838672622783970775653085652971888667064482151030822018565974084164812785937167067899265071806883189425808652614041346698609430428488623420867004775841831737139272403718817301879754589951077983369859385368318809992517855682694872534538862937538545227595881495646173926384613674206105836908073825850547714481997228126103022280543137613384164844604733917034425561783854025917174233571273088420726961501571798407502539168274663967684401560564643528658155154341567883345191932615679686743952146121930966280400203143164167037724051

  Validity: [From: Mon Dec 04 10:42:29 CET 2017,
               To: Sat Jan 01 00:59:59 CET 10000]
  Issuer: CN=bob smith, OU=jboss, O=red hat, L=raleigh, ST=north carolina, C=us
  SerialNumber: [1965736310424294143]

Certificate Extensions: 7
[1]: ObjectId: 1.3.6.1.5.5.7.1.11 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 38 30 36 30 10 06 08  2b 06 01 05 05 07 30 03  .8060.........0.
0010: 87 04 0b 16 21 2c 30 22  06 08 2b 06 01 05 05 07  ......0.........
0020: 30 05 86 16 68 74 74 70  3a 2f 2f 61 6e 6f 74 68  0...http...anoth
0030: 65 72 2e 75 72 6c 2e 63  6f 6d                    er.url.com


[2]: ObjectId: 2.5.29.18 Criticality=false
IssuerAlternativeName [
[IPAddress: 10.20.30.40, URIName: http://some.url.com]]

[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_CertSign
  Crl_Sign
]

[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 4d cb ee b6 cf 01 78 b7  d3 5c 65 16 96 a2 3c 4b  M.....x...e....K
0010: e8 d8 5f a0                                        ....
]
]

[5]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2
]

[6]: ObjectId: 2.5.29.37 Criticality=false
ExtKeyUsage [
	1.3.6.1.5.5.7.3.2	1.3.6.1.5.5.7.3.8]

[7]: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
[RFC822Name: bobsmith at example.com, DNSName: bobsmith.example.com]]

Unparseable certificate extensions: 1
[1]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
0000: 30 3f 30 1c 06 08 2b 06  01 05 05 07 30 01 86 10  0.0.........0...
0010: 31 30 2e 32 30 2e 33 30  2e 34 30 3a 38 30 38 30  10.20.30.40.8080
0020: 30 1f 06 08 2b 06 01 05  05 07 30 02 82 13 69 73  0.........0...is
0030: 73 75 65 72 73 2e 65 78  61 6d 70 6c 65 2e 63 6f  suers.example.co
0040: 6d                                                 m

]
  Algorithm: [SHA256withDSA]
  Signature:
0000: 30 45 02 21 00 a8 4a dc  8b 0e a3 bd 55 7f 78 2a  0E....J.....U.x.
0010: 4e 68 17 b7 72 34 7d d0  77 c6 31 1e 00 ea f0 23  Nh..r4..w.1.....
0020: 06 a9 54 dd 7d 02 20 1b  19 b9 ef 4b 73 42 8b 4c  ..T........KsB.L
0030: d5 19 a7 1e 86 1c 44 60  24 2c dc b1 29 1a bc 89  ......D.........
0040: e9 92 01 b2 55 fd 90                               ....U..

]
{noformat}

> SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues fails on IBM JDK
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-1458
>                 URL: https://issues.jboss.org/browse/ELY-1458
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Certificate Authority
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>
> With IBM java
> {noformat}
> java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> {noformat}
> run test
> {noformat}
>  mvn test -Dtest=SelfSignedX509CertificateAndSigningKeyTest
> [INFO] Running org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.372 s <<< FAILURE! - in org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] testSelfSignedCertificateWithStringExtensionValues(org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest)  Time elapsed: 0.274 s  <<< FAILURE!
> java.lang.AssertionError
> 	at org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues(SelfSignedX509CertificateAndSigningKeyTest.java:197)
> {noformat}
> This is test line failing
> {code:java|title=SelfSignedX509CertificateAndSigningKeyTest.java}
>         byte[] authorityInfoAccessExtension = certificate.getExtensionValue(X500.OID_PE_AUTHORITY_INFO_ACCESS);
>         assertNotNull(authorityInfoAccessExtension);
> {code}



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

From issues at jboss.org  Mon Dec  4 05:12:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 4 Dec 2017 05:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2157) DMN Editor: Contexts: Add
 special behaviour of last row
In-Reply-To: <JIRA.12722941.1512047645000@Atlassian.JIRA>
References: <JIRA.12722941.1512047645000@Atlassian.JIRA>
	<JIRA.12722941.1512047645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722941.1512047645000.73239.1512382320136@Atlassian.JIRA>


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

Jozef Marko updated DROOLS-2157:
--------------------------------
    QE Status: ON_QA  (was: NEW)


> DMN Editor: Contexts: Add special behaviour of last row
> -------------------------------------------------------
>
>                 Key: DROOLS-2157
>                 URL: https://issues.jboss.org/browse/DROOLS-2157
>             Project: Drools
>          Issue Type: Enhancement
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> The last row of a {{Context}} should span all columns and populate the last {{ContextEntry}} in the {{Context}}. It should not have a variable. This is the XML for a _regular_ row and the _final_ row:
> {code}
> <semantic:context id="_f4f86e5f-e3e3-4b99-9260-8086764e598f">
>       <semantic:contextEntry>
>         <semantic:variable id="_779ca919-15d8-48d0-a9f0-e0203e60fac6" name="in1"/>
>         <semantic:literalExpression id="_4b8b8cc1-a56c-4673-8334-96e178cd04a4">
>           <semantic:text>"literal exp" </semantic:text>
>         </semantic:literalExpression>
>       </semantic:contextEntry>
>       <semantic:contextEntry>
>         <semantic:literalExpression id="_297181da-d0d5-4137-960b-34836d5570e5">
>           <semantic:text>"result"  </semantic:text>
>         </semantic:literalExpression>
>       </semantic:contextEntry>
>     </semantic:context>
> {code}



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

From issues at jboss.org  Mon Dec  4 05:40:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 4 Dec 2017 05:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2239) AUTH + ASYM_ENCRYPT causes
 problem with re-joining cluster (MERGE)
In-Reply-To: <JIRA.12723237.1512373185000@Atlassian.JIRA>
References: <JIRA.12723237.1512373185000@Atlassian.JIRA>
	<JIRA.12723237.1512373185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723237.1512373185000.73341.1512384000641@Atlassian.JIRA>


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

Bela Ban updated JGRP-2239:
---------------------------
    Fix Version/s: 4.0.9


> AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)
> ------------------------------------------------------------------
>
>                 Key: JGRP-2239
>                 URL: https://issues.jboss.org/browse/JGRP-2239
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.6
>         Environment: Infinispan 9.1.1 + JGroups 4.0.6.Final + Vert.x 3.5.0
>            Reporter: Boris Sh
>            Assignee: Bela Ban
>             Fix For: 4.0.9
>
>
> Hello,
> I am using the following configuration:
> {code:java}
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> 	<UDP />
> 	<PING />
> 	<MERGE3 />
> 	<FD />
> 	<VERIFY_SUSPECT />
> 	<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
> 		sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
> 		asym_algorithm="RSA" />
> 	<pbcast.NAKACK2 />
> 	<UNICAST3 />
> 	<pbcast.STABLE />
> 	<FRAG2 />
> 	<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
> 		keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
> 		cipher_type="RSA" />
> 	<pbcast.GMS />
> </config>
> {code}
> I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.
> Initially, when these nodes join the cluster, everything is fine.
> The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):
> {code:java}
> org.jgroups.protocols.FD up
> WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
>  org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-36734
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> {code}
> so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".
> In cluster coordinator logs I see the following:
> {code:java}
> INFO: ISPN100000: Node node-26978 joined the cluster
> ****
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> org.jgroups.logging.Slf4jLogImpl error
> ERROR: key requester  node-26978 is not in current view [***]; ignoring key request
> org.jgroups.logging.Slf4jLogImpl warn
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]
> {code}
> My understanding of what has happened:
> For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens.
> How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, as the key doesn't change.
> Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.
> So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.



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

From issues at jboss.org  Mon Dec  4 06:13:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 4 Dec 2017 06:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9591) Add ParameterCorrector to
 attributes representing Artemis addresses
In-Reply-To: <JIRA.12723267.1512385965000@Atlassian.JIRA>
References: <JIRA.12723267.1512385965000@Atlassian.JIRA>
	<JIRA.12723267.1512385965659@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723267.1512385965000.73871.1512385980800@Atlassian.JIRA>

Jeff Mesnil created WFLY-9591:
---------------------------------

             Summary: Add ParameterCorrector to attributes representing Artemis addresses
                 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  Mon Dec  4 06:14:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 4 Dec 2017 06:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9591) Correct attributes
 representing Artemis addresses
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.73880.1512386040504@Atlassian.JIRA>


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

Jeff Mesnil updated WFLY-9591:
------------------------------
    Summary: Correct attributes representing Artemis addresses  (was: Add ParameterCorrector to attributes representing Artemis addresses)


> Correct attributes representing Artemis addresses
> -------------------------------------------------
>
>                 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  Mon Dec  4 06:51:00 2017
From: issues at jboss.org (Herve Remisio (JIRA))
Date: Mon, 4 Dec 2017 06:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2162) Error evaluating constraint
In-Reply-To: <JIRA.12723281.1512388250000@Atlassian.JIRA>
References: <JIRA.12723281.1512388250000@Atlassian.JIRA>
	<JIRA.12723281.1512388250223@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723281.1512388250000.74230.1512388260807@Atlassian.JIRA>

Herve Remisio created DROOLS-2162:
-------------------------------------

             Summary: Error evaluating constraint
                 Key: DROOLS-2162
                 URL: https://issues.jboss.org/browse/DROOLS-2162
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.4.1.Final
            Reporter: Herve Remisio
            Assignee: Mario Fusco
            Priority: Blocker
         Attachments: 2017-12-04_12-33-29.png

We detected a very strange behavior when processing Rules that contain expressions like "...startsWith(..".

 !2017-12-04_12-33-29.png|thumbnail! 

Sometimes this error disappears when we simply re-upload the Rule file and it gets recompiled.



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

From issues at jboss.org  Mon Dec  4 07:28:00 2017
From: issues at jboss.org (Fedor Gavrilov (JIRA))
Date: Mon, 4 Dec 2017 07:28:00 -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.74408.1512390480516@Atlassian.JIRA>


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

Fedor Gavrilov reassigned DROOLS-2161:
--------------------------------------

    Assignee: Fedor Gavrilov  (was: Edson Tirelli)


> 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  Mon Dec  4 08:16:00 2017
From: issues at jboss.org (Marcus Handte (JIRA))
Date: Mon, 4 Dec 2017 08:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9592) Arrays in Method Parameters
 are causing EJBAccessException for @PermitAll Methods
In-Reply-To: <JIRA.12723297.1512393345000@Atlassian.JIRA>
References: <JIRA.12723297.1512393345000@Atlassian.JIRA>
	<JIRA.12723297.1512393345047@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723297.1512393345000.74758.1512393360281@Atlassian.JIRA>

Marcus Handte created WFLY-9592:
-----------------------------------

             Summary: Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
                 Key: WFLY-9592
                 URL: https://issues.jboss.org/browse/WFLY-9592
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 10.1.0.Final
         Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test
            Reporter: Marcus Handte
            Priority: Minor


EJB methods with array parameters are causing EJBAccessExceptions when they are annotated with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see WFLY-1658). But it seems to be present again in 10.1.0.Final.

For my own use case, this is not a problem since I can simply change the method signatures to use lists instead of arrays. However, I can imagine that this could be a more significant problem for people trying to run existing code that they do not want to (or cannot) touch.



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

From issues at jboss.org  Mon Dec  4 08:17:00 2017
From: issues at jboss.org (Marcus Handte (JIRA))
Date: Mon, 4 Dec 2017 08:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1658) EJBAccessException for
 methods with @PermitAll but using arrays in parameters
In-Reply-To: <JIRA.12495941.1373301132000@Atlassian.JIRA>
References: <JIRA.12495941.1373301132000@Atlassian.JIRA>
	<JIRA.12495941.1373301132000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495941.1373301132000.74773.1512393420665@Atlassian.JIRA>


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

Marcus Handte commented on WFLY-1658:
-------------------------------------

Sure. The new bug is WFLY-9592.

> EJBAccessException for methods with @PermitAll but using arrays in parameters
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1658
>                 URL: https://issues.jboss.org/browse/WFLY-1658
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha2
>         Environment: 8.0.0.Alpha2 / Oracle JDK 7
>            Reporter: Christophe Fillot
>            Assignee: jaikiran pai
>              Labels: ejb, security-domain
>             Fix For: 8.0.0.Alpha3
>
>
> Calling an EJB method containing an array in parameters throws EJBAccessException, even if the method has @PermitAll annotation.



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

From issues at jboss.org  Mon Dec  4 08:43:00 2017
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Mon, 4 Dec 2017 08:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2780) Improve buffer-pool model
	description
In-Reply-To: <JIRA.12691261.1494331448000@Atlassian.JIRA>
References: <JIRA.12691261.1494331448000@Atlassian.JIRA>
	<JIRA.12691261.1494331448000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12691261.1494331448000.75010.1512394980218@Atlassian.JIRA>


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

Romain Pelisse updated WFCORE-2780:
-----------------------------------
    Description: 
Current state of buffer-pool model description:
{code}
[standalone at localhost:9990 /] /subsystem=io/buffer-pool=foo:read-resource-description
{             
    "outcome" => "success",
    "result" => {
        "description" => "Defines buffer pool",
        "capabilities" => [{
            "name" => "org.wildfly.io.buffer-pool",
            "dynamic" => true
        }],
        "attributes" => {
            "buffer-size" => {
                "type" => INT,
                "description" => "The size of each buffer slice in bytes, if not set optimal value is calculated based on available RAM resources in your system.",
                "expressions-allowed" => true,
                "required" => false,
                "nillable" => true,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "all-services"
            },
            "buffers-per-slice" => {
                "type" => INT,
                "description" => "How many buffers per slice, if not set optimal value is calculated based on available RAM resources in your system.",
                "expressions-allowed" => true,
                "required" => false,
                "nillable" => true,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "all-services"
            },
            "direct-buffers" => {
                "type" => BOOLEAN,
                "description" => "Does the buffer pool use direct buffers, some platforms don't support direct buffers",
                "expressions-allowed" => true,
                "required" => false,
                "nillable" => true,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "all-services"
            }
        },
        "operations" => undefined,
        "notifications" => undefined,
        "children" => {}
    }
}
{code}

Following improvements should be done to it:

* In {{buffer-size}} and {{buffers-per-slice}} description there is mentioned something called 'slice'. Nowhere is described what it is. Suggested improvement: Explain what slice is, preferably in buffer-pool model description.
* In {{buffer-size}} and {{buffers-per-slice}} description there is this sentence: ''...if not set optimal value is calculated based on available RAM resources in your system" - how it is calculated? Is there any default fixed value? User would like to know this. Suggestion: Add explanation about default value.
* In {{direct-buffers}} description there is mentioned that some platforms don't support direct buffers? Is there mentioned which one or what determines whether direct buffers are supported on given platform? Suggested improvement: Explain what element determines whether direct buffers are supported.


> Improve buffer-pool model description
> -------------------------------------
>
>                 Key: WFCORE-2780
>                 URL: https://issues.jboss.org/browse/WFCORE-2780
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Romain Pelisse
>            Assignee: Romain Pelisse
>            Priority: Minor
>
> Current state of buffer-pool model description:
> {code}
> [standalone at localhost:9990 /] /subsystem=io/buffer-pool=foo:read-resource-description
> {             
>     "outcome" => "success",
>     "result" => {
>         "description" => "Defines buffer pool",
>         "capabilities" => [{
>             "name" => "org.wildfly.io.buffer-pool",
>             "dynamic" => true
>         }],
>         "attributes" => {
>             "buffer-size" => {
>                 "type" => INT,
>                 "description" => "The size of each buffer slice in bytes, if not set optimal value is calculated based on available RAM resources in your system.",
>                 "expressions-allowed" => true,
>                 "required" => false,
>                 "nillable" => true,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "all-services"
>             },
>             "buffers-per-slice" => {
>                 "type" => INT,
>                 "description" => "How many buffers per slice, if not set optimal value is calculated based on available RAM resources in your system.",
>                 "expressions-allowed" => true,
>                 "required" => false,
>                 "nillable" => true,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "all-services"
>             },
>             "direct-buffers" => {
>                 "type" => BOOLEAN,
>                 "description" => "Does the buffer pool use direct buffers, some platforms don't support direct buffers",
>                 "expressions-allowed" => true,
>                 "required" => false,
>                 "nillable" => true,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "all-services"
>             }
>         },
>         "operations" => undefined,
>         "notifications" => undefined,
>         "children" => {}
>     }
> }
> {code}
> Following improvements should be done to it:
> * In {{buffer-size}} and {{buffers-per-slice}} description there is mentioned something called 'slice'. Nowhere is described what it is. Suggested improvement: Explain what slice is, preferably in buffer-pool model description.
> * In {{buffer-size}} and {{buffers-per-slice}} description there is this sentence: ''...if not set optimal value is calculated based on available RAM resources in your system" - how it is calculated? Is there any default fixed value? User would like to know this. Suggestion: Add explanation about default value.
> * In {{direct-buffers}} description there is mentioned that some platforms don't support direct buffers? Is there mentioned which one or what determines whether direct buffers are supported on given platform? Suggested improvement: Explain what element determines whether direct buffers are supported.



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

From issues at jboss.org  Mon Dec  4 08:46:02 2017
From: issues at jboss.org (Fedor Gavrilov (JIRA))
Date: Mon, 4 Dec 2017 08:46:02 -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.75059.1512395162419@Atlassian.JIRA>


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

Fedor Gavrilov commented on DROOLS-2161:
----------------------------------------

java.lang.AssertionError: DMNMessage{ severity=ERROR, type=FAILED_XML_VALIDATION, message='Failed XML validation of DMN file: cvc-elt.1: Cannot find the declaration of element 'semantic:definitions'.', sourceId='null', exception='SAXParseException : cvc-elt.1: Cannot find the declaration of element 'semantic:definitions'.', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'h' is missing its type reference on node 'x'', sourceId='_95c8b5cc-4dd3-4a7b-bd93-d2f709c88bf2', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'g' is missing its type reference on node 'x'', sourceId='_9e512834-3b21-47ec-902b-5e9525b01f07', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'new list' is missing its type reference on node 'x'', sourceId='_7aad66b5-f3a7-4eae-a717-3c94eeb3858d', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'x' is missing its type reference on node 'x'', sourceId='_eb1123e4-ddd4-44d7-8103-7a8d1523c7d0', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'list' is missing its type reference on node 'x'', sourceId='_234ad53b-b2e2-4cb4-b578-1d22546d06af', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'limit' is missing its type reference on node 'x'', sourceId='_632ea9f5-c827-47ee-926f-0973466e99b6', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'n' is missing its type reference on node 'x'', sourceId='_a4180fb5-08f5-4bff-a56c-bc9ee9e98939', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression 'if n + 1 > limit then
    new list
else
    f( n+1, limit, new list )' for name 'f' on node 'x': Unknown variable 'f'', sourceId='_89fb1571-a993-46fe-a8a7-0b51e11614a0', exception='', feelEvent='UnknownVariableErrorEvent : Unknown variable 'f''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression 'if n + 1 > limit then
    append( list, n )
else
    h( n+1, limit, append( list, n ) )' for name 'h' on node 'x': Unknown variable 'h'', sourceId='_a8c548dd-77e4-4a9e-8490-4485754433f4', exception='', feelEvent='UnknownVariableErrorEvent : Unknown variable 'h''}

> 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  Mon Dec  4 08:55:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 4 Dec 2017 08:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9592) Arrays in Method Parameters
 are causing EJBAccessException for @PermitAll Methods
In-Reply-To: <JIRA.12723297.1512393345000@Atlassian.JIRA>
References: <JIRA.12723297.1512393345000@Atlassian.JIRA>
	<JIRA.12723297.1512393345000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723297.1512393345000.75156.1512395700743@Atlassian.JIRA>


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

Tomaz Cerar closed WFLY-9592.
-----------------------------
    Resolution: Out of Date


Please check if it works in WildFly 11 and reopen if it does.
WF11 has completely new security layer.

> Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-9592
>                 URL: https://issues.jboss.org/browse/WFLY-9592
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test
>            Reporter: Marcus Handte
>            Priority: Minor
>
> EJB methods with array parameters are causing EJBAccessExceptions when they are annotated with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see WFLY-1658). But it seems to be present again in 10.1.0.Final.
> For my own use case, this is not a problem since I can simply change the method signatures to use lists instead of arrays. However, I can imagine that this could be a more significant problem for people trying to run existing code that they do not want to (or cannot) touch.



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

From issues at jboss.org  Mon Dec  4 08:56:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Mon, 4 Dec 2017 08:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2157) DMN Editor: Contexts: Add
 special behaviour of last row
In-Reply-To: <JIRA.12722941.1512047645000@Atlassian.JIRA>
References: <JIRA.12722941.1512047645000@Atlassian.JIRA>
	<JIRA.12722941.1512047645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722941.1512047645000.75174.1512395760618@Atlassian.JIRA>


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

Michael Anstis resolved DROOLS-2157.
------------------------------------
    Resolution: Done


> DMN Editor: Contexts: Add special behaviour of last row
> -------------------------------------------------------
>
>                 Key: DROOLS-2157
>                 URL: https://issues.jboss.org/browse/DROOLS-2157
>             Project: Drools
>          Issue Type: Enhancement
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> The last row of a {{Context}} should span all columns and populate the last {{ContextEntry}} in the {{Context}}. It should not have a variable. This is the XML for a _regular_ row and the _final_ row:
> {code}
> <semantic:context id="_f4f86e5f-e3e3-4b99-9260-8086764e598f">
>       <semantic:contextEntry>
>         <semantic:variable id="_779ca919-15d8-48d0-a9f0-e0203e60fac6" name="in1"/>
>         <semantic:literalExpression id="_4b8b8cc1-a56c-4673-8334-96e178cd04a4">
>           <semantic:text>"literal exp" </semantic:text>
>         </semantic:literalExpression>
>       </semantic:contextEntry>
>       <semantic:contextEntry>
>         <semantic:literalExpression id="_297181da-d0d5-4137-960b-34836d5570e5">
>           <semantic:text>"result"  </semantic:text>
>         </semantic:literalExpression>
>       </semantic:contextEntry>
>     </semantic:context>
> {code}



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

From issues at jboss.org  Mon Dec  4 09:30:00 2017
From: issues at jboss.org (Fedor Gavrilov (JIRA))
Date: Mon, 4 Dec 2017 09:30:00 -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.75364.1512397800738@Atlassian.JIRA>


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

Fedor Gavrilov edited comment on DROOLS-2161 at 12/4/17 9:30 AM:
-----------------------------------------------------------------

java.lang.AssertionError: DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'h' is missing its type reference on node 'x'', sourceId='_95c8b5cc-4dd3-4a7b-bd93-d2f709c88bf2', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'g' is missing its type reference on node 'x'', sourceId='_9e512834-3b21-47ec-902b-5e9525b01f07', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'new list' is missing its type reference on node 'x'', sourceId='_7aad66b5-f3a7-4eae-a717-3c94eeb3858d', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'x' is missing its type reference on node 'x'', sourceId='_eb1123e4-ddd4-44d7-8103-7a8d1523c7d0', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'list' is missing its type reference on node 'x'', sourceId='_234ad53b-b2e2-4cb4-b578-1d22546d06af', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'limit' is missing its type reference on node 'x'', sourceId='_632ea9f5-c827-47ee-926f-0973466e99b6', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'n' is missing its type reference on node 'x'', sourceId='_a4180fb5-08f5-4bff-a56c-bc9ee9e98939', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, type=TYPE_DEF_NOT_FOUND, message='Unable to resolve type reference 'tNumberList' on node 'x'', sourceId='_2f139270-6d81-4f0b-bf26-c85bd90033b1', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, type=TYPE_DEF_NOT_FOUND, message='Unable to resolve type reference 'tNumberList' on node 'x'', sourceId='_8fe8d041-5a54-4377-ae5f-83e1b632e033', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression 'append( list, n )' for name 'new list' on node 'x': Exception raised: NullPointerException', sourceId='_ce0a3445-cc1f-47a9-88b5-bd3f1c00c752', exception='NullPointerException : null', feelEvent=''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression 'if n + 1 > limit then
      new list
  else
      f( n+1, limit, new list )' for name 'f' on node 'x': Exception raised: NullPointerException', sourceId='_89fb1571-a993-46fe-a8a7-0b51e11614a0', exception='NullPointerException : null', feelEvent=''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression 'function( n, limit, list ) {
      new list : append( list, n ),
      result : if n + 1 > limit then
                        new list
                   else
                       g( n+1, limit, new list )
  }.result' for name 'g' on node 'x': Exception raised: NullPointerException', sourceId='_608dfc35-d13e-459a-998b-08ce33a48ca8', exception='NullPointerException : null', feelEvent=''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression 'if n + 1 > limit then
      append( list, n )
  else
      h( n+1, limit, append( list, n ) )' for name 'h' on node 'x': Exception raised: NullPointerException', sourceId='_a8c548dd-77e4-4a9e-8490-4485754433f4', exception='NullPointerException : null', feelEvent=''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression '[ f( 1, 3, []), g( 1, 3, []), h( 1, 3, []) ]' for name 'x' on node 'x': Exception raised: NullPointerException', sourceId='_7e88403e-717f-4753-a747-a65368f7cd05', exception='NullPointerException : null', feelEvent=''}


was (Author: fedor.gavrilov):
java.lang.AssertionError: DMNMessage{ severity=ERROR, type=FAILED_XML_VALIDATION, message='Failed XML validation of DMN file: cvc-elt.1: Cannot find the declaration of element 'semantic:definitions'.', sourceId='null', exception='SAXParseException : cvc-elt.1: Cannot find the declaration of element 'semantic:definitions'.', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'h' is missing its type reference on node 'x'', sourceId='_95c8b5cc-4dd3-4a7b-bd93-d2f709c88bf2', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'g' is missing its type reference on node 'x'', sourceId='_9e512834-3b21-47ec-902b-5e9525b01f07', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'new list' is missing its type reference on node 'x'', sourceId='_7aad66b5-f3a7-4eae-a717-3c94eeb3858d', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Variable named 'x' is missing its type reference on node 'x'', sourceId='_eb1123e4-ddd4-44d7-8103-7a8d1523c7d0', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'list' is missing its type reference on node 'x'', sourceId='_234ad53b-b2e2-4cb4-b578-1d22546d06af', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'limit' is missing its type reference on node 'x'', sourceId='_632ea9f5-c827-47ee-926f-0973466e99b6', exception='', feelEvent=''}
DMNMessage{ severity=WARN, type=MISSING_TYPE_REF, message='Parameter named 'n' is missing its type reference on node 'x'', sourceId='_a4180fb5-08f5-4bff-a56c-bc9ee9e98939', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression 'if n + 1 > limit then
    new list
else
    f( n+1, limit, new list )' for name 'f' on node 'x': Unknown variable 'f'', sourceId='_89fb1571-a993-46fe-a8a7-0b51e11614a0', exception='', feelEvent='UnknownVariableErrorEvent : Unknown variable 'f''}
DMNMessage{ severity=ERROR, type=ERR_COMPILING_FEEL, message='Error compiling FEEL expression 'if n + 1 > limit then
    append( list, n )
else
    h( n+1, limit, append( list, n ) )' for name 'h' on node 'x': Unknown variable 'h'', sourceId='_a8c548dd-77e4-4a9e-8490-4485754433f4', exception='', feelEvent='UnknownVariableErrorEvent : Unknown variable 'h''}

> 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  Mon Dec  4 09:41:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 4 Dec 2017 09:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9587) Investigate and introduce
 capabilities for the transactional subsytems transations/xts/rts
In-Reply-To: <JIRA.12722888.1512034178000@Atlassian.JIRA>
References: <JIRA.12722888.1512034178000@Atlassian.JIRA>
	<JIRA.12722888.1512034178000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722888.1512034178000.75437.1512398460315@Atlassian.JIRA>


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

Brian Stansberry commented on WFLY-9587:
----------------------------------------

Re: jts, for expressions we had a pretty simple policy. All attributes must support expressions except those whose value:

1) Is a model reference (e.g. socket-binding=http).
2) Is a class or module name.

We had a simple policy because otherwise we'd end up with a really inconsistent API where different devs make different decisions about expression support, often coming down to "I don't think it's really needed for this one." That's what we had in AS 7.1 / EAP 6.0 which led to quite a number of bug reports where users disagreed and wanted the expression. We added the current policy in AS 7.2.

Now I think we need a 3rd category:

3) Controls whether an optional capability is installed or an optional requirement is added.

I believe there are only a few such attributes, maybe just this one. But I'm reluctant to break compatibility and drop expressions support altogether, not when it can be made to work for all but the real corner case of using a vault expression. Logging some sort of "expression deprecation" thing would be good though; something to help state that we advise against using an expression, helping to drive users away from it so that if we need to in some future release we can drop support and clean things out.  For WFCORE-887 I have a similar need. I'll look into making the solution to that easily adapted to other cases. For example, just call setExpressionDeprecated() on the AttributeDefinition builder and then the kernel handles the logging.

> Investigate and introduce capabilities for the transactional subsytems transations/xts/rts
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9587
>                 URL: https://issues.jboss.org/browse/WFLY-9587
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Transactions, XTS
>    Affects Versions: 11.0.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> The notion of capability is not introduced to the transactional system. The WFLY integration expecting subsystem providing it. The transaction subsystems should support so.
> https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities



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

From issues at jboss.org  Mon Dec  4 09:42:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 4 Dec 2017 09:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.75443.1512398520375@Atlassian.JIRA>


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

Brian Stansberry commented on WFCORE-887:
-----------------------------------------

Discussion of WFLY-9587 shows a possible other scenario where this kind of "deprecation" might be useful. So we should try to make the facility generic.

> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
>                 Key: WFCORE-887
>                 URL: https://issues.jboss.org/browse/WFCORE-887
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Alpha5
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We should look for other cases like this too, although those changes should be separate JIRAs. 



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

From issues at jboss.org  Mon Dec  4 09:48:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 4 Dec 2017 09:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-202) Introduce usage of
 TestCaseNeeded to bugzilla workflow
In-Reply-To: <JIRA.12723324.1512398878000@Atlassian.JIRA>
References: <JIRA.12723324.1512398878000@Atlassian.JIRA>
	<JIRA.12723324.1512398878101@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723324.1512398878000.75498.1512398880376@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-202:
----------------------------------------

             Summary: Introduce usage of TestCaseNeeded to bugzilla workflow
                 Key: HAWKULARQE-202
                 URL: https://issues.jboss.org/browse/HAWKULARQE-202
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Filip Brychta
            Assignee: Michael Foley


We need to introduce TestCaseNeeded bugzilla keyword to our workflow.
This keyword should be used for all issues which are not covered by polarion test cases yet.

Following should be done:
* introduce the usage to our bugzilla workflow documents
* notify team to start using it
* got through older issues and add the keyword where necessary
* prepare query which will list issues with this keyword sorted by severity and share it with the team so every team member can pick some issue from the list and create polarion case
* when the case is crated the keyword should be removed



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

From issues at jboss.org  Mon Dec  4 09:49:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 4 Dec 2017 09:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3442) CLI can't reload if
 authentication configuration changed
In-Reply-To: <JIRA.12723325.1512398892000@Atlassian.JIRA>
References: <JIRA.12723325.1512398892000@Atlassian.JIRA>
	<JIRA.12723325.1512398892408@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723325.1512398892000.75500.1512398940097@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3442:
--------------------------------------------

             Summary: CLI can't reload if authentication configuration changed
                 Key: WFCORE-3442
                 URL: https://issues.jboss.org/browse/WFCORE-3442
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


The context:
- Legacy ManagementRealm, no local-auth enabled, only users located properties file.
- SASL authentication factory, digest with FooRealm, userName/password in other properties file

The http management interface
- Reference ManagementRealm and upgrade references SAL factory.

>From CLI:
1) User connects using credentials required for FooRealm
2) User disables SASL authentication : /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory,value=undefined
3) User reloads ==> Connection fails.

The user should be prompted for ManagementRealm credentials (if the current ones are not valid in the context of this realm).

Furthermore, ConnectionInfo should expose the realm the CLI is connected to.




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

From issues at jboss.org  Mon Dec  4 09:51:10 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1553) Write documentation for the
 DMN and FEEL components
In-Reply-To: <JIRA.12690982.1494094461000@Atlassian.JIRA>
References: <JIRA.12690982.1494094461000@Atlassian.JIRA>
	<JIRA.12690982.1494094461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12690982.1494094461000.75592.1512399070582@Atlassian.JIRA>


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

Kris Verlaenen updated DROOLS-1553:
-----------------------------------
    Sprint: 2017 Week 22-23, 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  (was: 2017 Week 22-23, 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)


> Write documentation for the DMN and FEEL components
> ---------------------------------------------------
>
>                 Key: DROOLS-1553
>                 URL: https://issues.jboss.org/browse/DROOLS-1553
>             Project: Drools
>          Issue Type: Task
>          Components: dmn engine
>    Affects Versions: 7.0.0.CR3
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 7.5.0.Final
>
>
> Write the documentation for both FEEL and DMN engines.



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

From issues at jboss.org  Mon Dec  4 09:51:10 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:10 -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.75605.1512399070855@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  (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)


> 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.5.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 Dec  4 09:51:11 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:11 -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.75610.1512399071028@Atlassian.JIRA>


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

Kris Verlaenen updated DROOLS-1811:
-----------------------------------
    Sprint: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50  (was: 2017 Week 45-46, 2017 Week 47-48)


> [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.5.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  Mon Dec  4 09:51:11 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:11 -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.75622.1512399071314@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  (was: 2017 Week 45-46, 2017 Week 47-48)


> [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 Dec  4 09:51:11 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:11 -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.75629.1512399071476@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  (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)


> 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 Dec  4 09:51:11 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:11 -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.75643.1512399071761@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  (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)


> [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 Dec  4 09:51:12 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:12 -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.75667.1512399072410@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  (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)


> 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 Dec  4 09:51:14 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:14 -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.75729.1512399074310@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  (was: 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48)


> [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 Dec  4 09:51:15 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:15 -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.75755.1512399075059@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  (was: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48)


> 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 Dec  4 09:51:15 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:15 -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.75764.1512399075314@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  (was: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48)


> 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 Dec  4 09:51:15 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:15 -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.75775.1512399075564@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  (was: 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48)


> [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 Dec  4 09:51:16 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2131) [DMN Editor] Boxed
 Expressions: Invocation editor
In-Reply-To: <JIRA.12720913.1510651966000@Atlassian.JIRA>
References: <JIRA.12720913.1510651966000@Atlassian.JIRA>
	<JIRA.12720913.1510651966000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720913.1510651966000.75795.1512399076113@Atlassian.JIRA>


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

Kris Verlaenen updated DROOLS-2131:
-----------------------------------
    Sprint: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50  (was: 2017 Week 45-46, 2017 Week 47-48)


> [DMN Editor] Boxed Expressions: Invocation editor
> -------------------------------------------------
>
>                 Key: DROOLS-2131
>                 URL: https://issues.jboss.org/browse/DROOLS-2131
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




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

From issues at jboss.org  Mon Dec  4 09:51:16 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2132) [DMN Editor] Boxed
 Expressions: FunctionDefinition editor
In-Reply-To: <JIRA.12720928.1510654087000@Atlassian.JIRA>
References: <JIRA.12720928.1510654087000@Atlassian.JIRA>
	<JIRA.12720928.1510654087000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720928.1510654087000.75798.1512399076165@Atlassian.JIRA>


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

Kris Verlaenen updated DROOLS-2132:
-----------------------------------
    Sprint: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50  (was: 2017 Week 45-46, 2017 Week 47-48)


> [DMN Editor] Boxed Expressions: FunctionDefinition editor
> ---------------------------------------------------------
>
>                 Key: DROOLS-2132
>                 URL: https://issues.jboss.org/browse/DROOLS-2132
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




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

From issues at jboss.org  Mon Dec  4 09:51:16 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 4 Dec 2017 09:51:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2136) Remove not used mvn
	dependencies
In-Reply-To: <JIRA.12721241.1510787234000@Atlassian.JIRA>
References: <JIRA.12721241.1510787234000@Atlassian.JIRA>
	<JIRA.12721241.1510787234000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721241.1510787234000.75801.1512399076259@Atlassian.JIRA>


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

Kris Verlaenen updated DROOLS-2136:
-----------------------------------
    Sprint: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50  (was: 2017 Week 45-46, 2017 Week 47-48)


> Remove not used mvn dependencies
> --------------------------------
>
>                 Key: DROOLS-2136
>                 URL: https://issues.jboss.org/browse/DROOLS-2136
>             Project: Drools
>          Issue Type: Task
>    Affects Versions: 7.4.1.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>
> In the drools-wb repository, remove all mvn dependencies that 
> {code:mvn}
> mvn dependency:analyze
> {code}
> marks as declared but not used



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

From issues at jboss.org  Mon Dec  4 09:51:17 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 4 Dec 2017 09:51:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3443) CLI ConnectionInfo should
 expose security realm.
In-Reply-To: <JIRA.12723326.1512399070000@Atlassian.JIRA>
References: <JIRA.12723326.1512399070000@Atlassian.JIRA>
	<JIRA.12723326.1512399070044@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723326.1512399070000.75838.1512399077198@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3443:
--------------------------------------------

             Summary: CLI ConnectionInfo should expose security realm.
                 Key: WFCORE-3443
                 URL: https://issues.jboss.org/browse/WFCORE-3443
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


This would allow to identify the authentication context the user is bound to.



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

From issues at jboss.org  Mon Dec  4 09:52:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 4 Dec 2017 09:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3442) CLI can't reload if
 authentication configuration changed
In-Reply-To: <JIRA.12723325.1512398892000@Atlassian.JIRA>
References: <JIRA.12723325.1512398892000@Atlassian.JIRA>
	<JIRA.12723325.1512398892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723325.1512398892000.75842.1512399120167@Atlassian.JIRA>


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

Jean-Francois Denise updated WFCORE-3442:
-----------------------------------------
    Description: 
The context:
- Legacy ManagementRealm, no local-auth enabled, only users located properties file.
- SASL authentication factory, digest with FooRealm, userName/password in other properties file

The http management interface
- Reference ManagementRealm and upgrade references SAL factory.

>From CLI:
1) User connects using credentials required for FooRealm
2) User disables SASL authentication : /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory,value=undefined
3) User reloads ==> Connection fails.

The user should be prompted for ManagementRealm credentials (if the current ones are not valid in the context of this realm).

  was:
The context:
- Legacy ManagementRealm, no local-auth enabled, only users located properties file.
- SASL authentication factory, digest with FooRealm, userName/password in other properties file

The http management interface
- Reference ManagementRealm and upgrade references SAL factory.

>From CLI:
1) User connects using credentials required for FooRealm
2) User disables SASL authentication : /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory,value=undefined
3) User reloads ==> Connection fails.

The user should be prompted for ManagementRealm credentials (if the current ones are not valid in the context of this realm).

Furthermore, ConnectionInfo should expose the realm the CLI is connected to.




> CLI can't reload if authentication configuration changed
> --------------------------------------------------------
>
>                 Key: WFCORE-3442
>                 URL: https://issues.jboss.org/browse/WFCORE-3442
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> The context:
> - Legacy ManagementRealm, no local-auth enabled, only users located properties file.
> - SASL authentication factory, digest with FooRealm, userName/password in other properties file
> The http management interface
> - Reference ManagementRealm and upgrade references SAL factory.
> From CLI:
> 1) User connects using credentials required for FooRealm
> 2) User disables SASL authentication : /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory,value=undefined
> 3) User reloads ==> Connection fails.
> The user should be prompted for ManagementRealm credentials (if the current ones are not valid in the context of this realm).



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

From issues at jboss.org  Mon Dec  4 09:55:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 4 Dec 2017 09:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-203) Intoduce usage of
 Regression bugzilla keyword
In-Reply-To: <JIRA.12723329.1512399294000@Atlassian.JIRA>
References: <JIRA.12723329.1512399294000@Atlassian.JIRA>
	<JIRA.12723329.1512399294306@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723329.1512399294000.75862.1512399300774@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-203:
----------------------------------------

             Summary: Intoduce usage of Regression bugzilla keyword
                 Key: HAWKULARQE-203
                 URL: https://issues.jboss.org/browse/HAWKULARQE-203
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Filip Brychta
            Assignee: Michael Foley
            Priority: Critical


We need to introduce Regression bugzilla keyword to our workflow.
This keyword should be used in cases when some already working feature delivered to customers is broken. All issues with this keyword must be fixed before the release -> everything which was working before should be working in newer version too.

Following should be done:
* introduce the usage to our bugzilla workflow document
* notify the whole team (including dev) to start using it
* prepare bugzilla query which will list all open issues with this keyword and share it with the team



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

From issues at jboss.org  Mon Dec  4 09:58:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 4 Dec 2017 09:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-204) Create best practices
 document for writing automation on mojo
In-Reply-To: <JIRA.12723330.1512399456000@Atlassian.JIRA>
References: <JIRA.12723330.1512399456000@Atlassian.JIRA>
	<JIRA.12723330.1512399456179@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723330.1512399456000.75877.1512399480085@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-204:
----------------------------------------

             Summary: Create best practices document for writing automation on mojo
                 Key: HAWKULARQE-204
                 URL: https://issues.jboss.org/browse/HAWKULARQE-204
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Filip Brychta
            Assignee: Filip Brychta


* create the document
* share it with the team



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

From issues at jboss.org  Mon Dec  4 10:00:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 4 Dec 2017 10:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-205) Create best practices
 document for polarion on mojo
In-Reply-To: <JIRA.12723331.1512399563000@Atlassian.JIRA>
References: <JIRA.12723331.1512399563000@Atlassian.JIRA>
	<JIRA.12723331.1512399563154@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723331.1512399563000.75884.1512399600423@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-205:
----------------------------------------

             Summary: Create best practices document for polarion on mojo
                 Key: HAWKULARQE-205
                 URL: https://issues.jboss.org/browse/HAWKULARQE-205
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Filip Brychta
            Assignee: Michael Foley


* create the document
* share it with the team 



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

From issues at jboss.org  Mon Dec  4 10:15:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 4 Dec 2017 10:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1553) Write documentation for the
 DMN and FEEL components
In-Reply-To: <JIRA.12690982.1494094461000@Atlassian.JIRA>
References: <JIRA.12690982.1494094461000@Atlassian.JIRA>
	<JIRA.12690982.1494094461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12690982.1494094461000.75957.1512400500926@Atlassian.JIRA>


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

Edson Tirelli updated DROOLS-1553:
----------------------------------
    Sprint: 2017 Week 22-23, 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  (was: 2017 Week 22-23, 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)


> Write documentation for the DMN and FEEL components
> ---------------------------------------------------
>
>                 Key: DROOLS-1553
>                 URL: https://issues.jboss.org/browse/DROOLS-1553
>             Project: Drools
>          Issue Type: Task
>          Components: dmn engine
>    Affects Versions: 7.0.0.CR3
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 7.5.0.Final
>
>
> Write the documentation for both FEEL and DMN engines.



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

From issues at jboss.org  Mon Dec  4 10:15:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 4 Dec 2017 10:15:00 -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.75960.1512400500997@Atlassian.JIRA>


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

Edson Tirelli updated DROOLS-2161:
----------------------------------
    Sprint: 2017 Week 49-50


> 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  Mon Dec  4 10:27:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 4 Dec 2017 10:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-206) Create long running
 complex environment
In-Reply-To: <JIRA.12723335.1512401190000@Atlassian.JIRA>
References: <JIRA.12723335.1512401190000@Atlassian.JIRA>
	<JIRA.12723335.1512401190620@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723335.1512401190000.76095.1512401220263@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-206:
----------------------------------------

             Summary: Create long running complex environment
                 Key: HAWKULARQE-206
                 URL: https://issues.jboss.org/browse/HAWKULARQE-206
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Filip Brychta
            Assignee: Michael Foley
            Priority: Critical


Goal of this task is to create environment which would be similar to customer environments.

Proposed steps (will be defined in more details later)
# define typical customer environment (probably secured, hybrid?-EAP running in OS/RHEV..., how many EAPs?, how many applications running, which metrics enabled...)
# dedicate hw resources
# install it
# keep it running as long as possible -> do upgrades the same way like customer would
# set up monitoring for errors
# set up regular reports



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

From issues at jboss.org  Mon Dec  4 10:31:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 4 Dec 2017 10:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3398) Elytron,
	wrong capabilities registered
In-Reply-To: <JIRA.12719233.1509631038000@Atlassian.JIRA>
References: <JIRA.12719233.1509631038000@Atlassian.JIRA>
	<JIRA.12719233.1509631038000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719233.1509631038000.76127.1512401460955@Atlassian.JIRA>


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

Ilia Vassilev updated WFCORE-3398:
----------------------------------
    Affects Version/s: 4.0.0.Alpha3


> Elytron, wrong capabilities registered
> --------------------------------------
>
>                 Key: WFCORE-3398
>                 URL: https://issues.jboss.org/browse/WFCORE-3398
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 4.0.0.Alpha3
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> I wen throught resources and 
> * trust-manager is registered as credential-store besides trust-manager
> {code}
>             "trust-manager" => {
>                 "description" => "A trust manager definition for creating the TrustManager[] as used to create an SSLContext.",
>                 "model-description" => {"*" => {
>                     "description" => "A trust manager definition for creating the TrustManager[] as used to create an SSLContext.",
>                     "capabilities" => [
>                         {
>                             "name" => "org.wildfly.security.trust-manager",
>                             "dynamic" => true
>                         },
>                         {
>                             "name" => "org.wildfly.security.credential-store",
>                             "dynamic" => true
>                         }
>                     ],
> {code}



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

From issues at jboss.org  Mon Dec  4 10:42:00 2017
From: issues at jboss.org (Michael Foley (JIRA))
Date: Mon, 4 Dec 2017 10:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-206) Create long running
 complex environment
In-Reply-To: <JIRA.12723335.1512401191000@Atlassian.JIRA>
References: <JIRA.12723335.1512401191000@Atlassian.JIRA>
	<JIRA.12723335.1512401191000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723335.1512401191000.76159.1512402120322@Atlassian.JIRA>


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

Michael Foley reassigned HAWKULARQE-206:
----------------------------------------

    Assignee: Matt Mahoney  (was: Michael Foley)


> Create long running complex environment
> ---------------------------------------
>
>                 Key: HAWKULARQE-206
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-206
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Filip Brychta
>            Assignee: Matt Mahoney
>            Priority: Critical
>
> Goal of this task is to create environment which would be similar to customer environments.
> Proposed steps (will be defined in more details later)
> # define typical customer environment (probably secured, hybrid?-EAP running in OS/RHEV..., how many EAPs?, how many applications running, which metrics enabled...)
> # dedicate hw resources
> # install it
> # keep it running as long as possible -> do upgrades the same way like customer would
> # set up monitoring for errors
> # set up regular reports



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

From issues at jboss.org  Mon Dec  4 10:45:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 4 Dec 2017 10:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2785) The
 HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache
 HttpClient
In-Reply-To: <JIRA.12691445.1494357087000@Atlassian.JIRA>
References: <JIRA.12691445.1494357087000@Atlassian.JIRA>
	<JIRA.12691445.1494357087000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12691445.1494357087000.76174.1512402300227@Atlassian.JIRA>


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

James Perkins reassigned WFCORE-2785:
-------------------------------------

    Assignee: James Perkins


> The HttpDeploymentUploadUnitTestCase needs to be rewritten to use the Apache HttpClient
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2785
>                 URL: https://issues.jboss.org/browse/WFCORE-2785
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The {{org.jboss.as.test.integration.management.http.HttpDeploymentUploadUnitTestCase}} uses the {{java.net.Authenticator.setDefault()}} to set a default authenticator. This can cause issues with tests that run after this test. The authenticator would be used after when the expectation is for the authentication to fail. This test should be converted to use the Apache {{HttpClient}} or at a minimum avoid setting a default authenticator.
> It also doesn't look like the test cleans up the deployed content which it should. -Maybe the {{add-content}} request could just be moved to the {{HttpGenericOperationUnitTestCase}} which has some similar actions.- See the {{HttpGenericOperationUnitTestCase}} for an example of using the {{HttpClient}} for a similar test.



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

From issues at jboss.org  Mon Dec  4 10:49:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 4 Dec 2017 10:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-123) [QE] - JMAN4-125 - Stop
 an EAP Domain - Sprint-68
In-Reply-To: <JIRA.12698018.1497891380000@Atlassian.JIRA>
References: <JIRA.12698018.1497891380000@Atlassian.JIRA>
	<JIRA.12698018.1497891380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12698018.1497891380000.76206.1512402540788@Atlassian.JIRA>


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

Hayk Hovsepyan resolved HAWKULARQE-123.
---------------------------------------
    Resolution: Done


> [QE] - JMAN4-125 - Stop an EAP Domain - Sprint-68
> -------------------------------------------------
>
>                 Key: HAWKULARQE-123
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-123
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>              Labels: 4.6
>
> See [JMAN4-125|https://issues.jboss.org/browse/JMAN4-125]
> Requirement's Test Plan: https://mojo.redhat.com/docs/DOC-1141233



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

From issues at jboss.org  Mon Dec  4 10:52:00 2017
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 4 Dec 2017 10:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1458)
 SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues
 fails on IBM JDK
In-Reply-To: <JIRA.12723253.1512380464000@Atlassian.JIRA>
References: <JIRA.12723253.1512380464000@Atlassian.JIRA>
	<JIRA.12723253.1512380464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723253.1512380464000.76222.1512402720505@Atlassian.JIRA>


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

Farah Juma reassigned ELY-1458:
-------------------------------

    Assignee: Farah Juma


> SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues fails on IBM JDK
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-1458
>                 URL: https://issues.jboss.org/browse/ELY-1458
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Certificate Authority
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Assignee: Farah Juma
>
> With IBM java
> {noformat}
> java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> {noformat}
> run test
> {noformat}
>  mvn test -Dtest=SelfSignedX509CertificateAndSigningKeyTest
> [INFO] Running org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.372 s <<< FAILURE! - in org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] testSelfSignedCertificateWithStringExtensionValues(org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest)  Time elapsed: 0.274 s  <<< FAILURE!
> java.lang.AssertionError
> 	at org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues(SelfSignedX509CertificateAndSigningKeyTest.java:197)
> {noformat}
> This is test line failing
> {code:java|title=SelfSignedX509CertificateAndSigningKeyTest.java}
>         byte[] authorityInfoAccessExtension = certificate.getExtensionValue(X500.OID_PE_AUTHORITY_INFO_ACCESS);
>         assertNotNull(authorityInfoAccessExtension);
> {code}



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

From issues at jboss.org  Mon Dec  4 10:53:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 4 Dec 2017 10:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-207) Define set of acceptance
	tests
In-Reply-To: <JIRA.12723347.1512402747000@Atlassian.JIRA>
References: <JIRA.12723347.1512402747000@Atlassian.JIRA>
	<JIRA.12723347.1512402747171@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723347.1512402747000.76239.1512402780431@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-207:
----------------------------------------

             Summary: Define set of acceptance tests
                 Key: HAWKULARQE-207
                 URL: https://issues.jboss.org/browse/HAWKULARQE-207
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Filip Brychta
            Assignee: Michael Foley
            Priority: Blocker


We need a set of cases which are considered to be "must work" which will be run every time before a release.

Example from JON:
- ssl configuration was not part of such suite and because of that one ugly issue was missed which resulted in unreachable agents after upgrade and critical hot-fix

Following should be done:
* define those cases for each area
* check that those cases are created in polarion
* set the highest possible severity for those cases
* define test run which will contain all those cases for each release
* automate as much as possible
* regularly check and update the suite with new features



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

From issues at jboss.org  Mon Dec  4 10:55:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 4 Dec 2017 10:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-208) Review MW QE Product
	Release Criteria
In-Reply-To: <JIRA.12723348.1512402859000@Atlassian.JIRA>
References: <JIRA.12723348.1512402859000@Atlassian.JIRA>
	<JIRA.12723348.1512402859339@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723348.1512402859000.76254.1512402900229@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-208:
----------------------------------------

             Summary: Review MW QE Product Release Criteria
                 Key: HAWKULARQE-208
                 URL: https://issues.jboss.org/browse/HAWKULARQE-208
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Filip Brychta
            Assignee: Michael Foley
            Priority: Critical


We need to review following document and create new tasks based on that.
https://mojo.redhat.com/docs/DOC-51572



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

From issues at jboss.org  Mon Dec  4 10:57:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 4 Dec 2017 10:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-209) Review security guide
In-Reply-To: <JIRA.12723349.1512402991000@Atlassian.JIRA>
References: <JIRA.12723349.1512402991000@Atlassian.JIRA>
	<JIRA.12723349.1512402991650@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723349.1512402991000.76264.1512403020615@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-209:
----------------------------------------

             Summary: Review security guide
                 Key: HAWKULARQE-209
                 URL: https://issues.jboss.org/browse/HAWKULARQE-209
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Filip Brychta
            Assignee: Michael Foley


We need to review following document and create new tasks based on that:
https://mojo.redhat.com/docs/DOC-164028 



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

From issues at jboss.org  Mon Dec  4 11:02:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 4 Dec 2017 11:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-210) Automation for checking
 missing metrics/config options on EAP
In-Reply-To: <JIRA.12723353.1512403280000@Atlassian.JIRA>
References: <JIRA.12723353.1512403280000@Atlassian.JIRA>
	<JIRA.12723353.1512403280814@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723353.1512403280000.76297.1512403320201@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-210:
----------------------------------------

             Summary: Automation for checking missing metrics/config options on EAP
                 Key: HAWKULARQE-210
                 URL: https://issues.jboss.org/browse/HAWKULARQE-210
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Filip Brychta
            Assignee: Michael Foley
            Priority: Optional


This tool should check for newly added metrics or configuration options for resources on EAP side.
e.g. following options were added in new version of EAP and we didn't have any way to catch it. - https://bugzilla.redhat.com/show_bug.cgi?id=1328440



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

From issues at jboss.org  Mon Dec  4 11:31:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 4 Dec 2017 11:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3443) CLI ConnectionInfo should
 expose security realm.
In-Reply-To: <JIRA.12723326.1512399070000@Atlassian.JIRA>
References: <JIRA.12723326.1512399070000@Atlassian.JIRA>
	<JIRA.12723326.1512399070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723326.1512399070000.76529.1512405060145@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-3443:
------------------------------------------

It should not be security realm as that is deprecated but we do have user administration and self service to start looking into so maybe some opportunities there.

> CLI ConnectionInfo should expose security realm.
> ------------------------------------------------
>
>                 Key: WFCORE-3443
>                 URL: https://issues.jboss.org/browse/WFCORE-3443
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> This would allow to identify the authentication context the user is bound to.



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

From issues at jboss.org  Mon Dec  4 11:33:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 4 Dec 2017 11:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3443) CLI ConnectionInfo should
 expose security realm.
In-Reply-To: <JIRA.12723326.1512399070000@Atlassian.JIRA>
References: <JIRA.12723326.1512399070000@Atlassian.JIRA>
	<JIRA.12723326.1512399070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723326.1512399070000.76536.1512405180306@Atlassian.JIRA>


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

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

[~dlofthouse], is the identity.realm returned by :whoami deprecated?
I was thinking to expose this information.

> CLI ConnectionInfo should expose security realm.
> ------------------------------------------------
>
>                 Key: WFCORE-3443
>                 URL: https://issues.jboss.org/browse/WFCORE-3443
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> This would allow to identify the authentication context the user is bound to.



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

From issues at jboss.org  Mon Dec  4 11:34:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 4 Dec 2017 11:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-29) Add support for module
	version strings
In-Reply-To: <JIRA.12722660.1511891076000@Atlassian.JIRA>
References: <JIRA.12722660.1511891076000@Atlassian.JIRA>
	<JIRA.12722660.1511891076000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722660.1511891076000.76552.1512405240962@Atlassian.JIRA>


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

David Lloyd resolved WFBUILD-29.
--------------------------------
    Resolution: Done


> Add support for module version strings
> --------------------------------------
>
>                 Key: WFBUILD-29
>                 URL: https://issues.jboss.org/browse/WFBUILD-29
>             Project: WildFly Build Tools
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.2.3.Final
>
>
> JBoss Modules supports version strings now.  Allow version numbers to derive from artifacts or be hard-coded in the source {{module.xml}}.



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

From issues at jboss.org  Mon Dec  4 11:39:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 4 Dec 2017 11:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3444) Update wildfly-build-tools
 to 1.2.3.Final
In-Reply-To: <JIRA.12723359.1512405487000@Atlassian.JIRA>
References: <JIRA.12723359.1512405487000@Atlassian.JIRA>
	<JIRA.12723359.1512405487700@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723359.1512405487000.76586.1512405540207@Atlassian.JIRA>

David Lloyd created WFCORE-3444:
-----------------------------------

             Summary: Update wildfly-build-tools to 1.2.3.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.Alpha5






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

From issues at jboss.org  Mon Dec  4 11:40:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 4 Dec 2017 11:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3445) Update jandex to 2.0.4.Final
In-Reply-To: <JIRA.12723360.1512405560000@Atlassian.JIRA>
References: <JIRA.12723360.1512405560000@Atlassian.JIRA>
	<JIRA.12723360.1512405560036@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723360.1512405560000.76589.1512405600313@Atlassian.JIRA>

Tomaz Cerar created WFCORE-3445:
-----------------------------------

             Summary: Update jandex to 2.0.4.Final
                 Key: WFCORE-3445
                 URL: https://issues.jboss.org/browse/WFCORE-3445
             Project: WildFly Core
          Issue Type: Sub-task
          Components: Server
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


Update to jandex 2.0.4.Final which has fix for JANDEX-41



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

From issues at jboss.org  Mon Dec  4 11:54:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 4 Dec 2017 11:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3443) CLI ConnectionInfo should
 expose security realm.
In-Reply-To: <JIRA.12723326.1512399070000@Atlassian.JIRA>
References: <JIRA.12723326.1512399070000@Atlassian.JIRA>
	<JIRA.12723326.1512399070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723326.1512399070000.76718.1512406440389@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-3443:
------------------------------------------

Yes in that case the name is used to refer to the security realm defined under core-services=management


> CLI ConnectionInfo should expose security realm.
> ------------------------------------------------
>
>                 Key: WFCORE-3443
>                 URL: https://issues.jboss.org/browse/WFCORE-3443
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> This would allow to identify the authentication context the user is bound to.



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

From issues at jboss.org  Mon Dec  4 11:56:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 4 Dec 2017 11:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-204) Create best practices
 document for writing automation on mojo
In-Reply-To: <JIRA.12723330.1512399456000@Atlassian.JIRA>
References: <JIRA.12723330.1512399456000@Atlassian.JIRA>
	<JIRA.12723330.1512399456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723330.1512399456000.76725.1512406560553@Atlassian.JIRA>


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

Filip Brychta commented on HAWKULARQE-204:
------------------------------------------

Created document https://mojo.redhat.com/docs/DOC-1157376

> Create best practices document for writing automation on mojo
> -------------------------------------------------------------
>
>                 Key: HAWKULARQE-204
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-204
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Filip Brychta
>            Assignee: Filip Brychta
>
> * create the document
> * share it with the team



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

From issues at jboss.org  Mon Dec  4 11:58:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 4 Dec 2017 11:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3443) CLI ConnectionInfo should
 expose security realm.
In-Reply-To: <JIRA.12723326.1512399070000@Atlassian.JIRA>
References: <JIRA.12723326.1512399070000@Atlassian.JIRA>
	<JIRA.12723326.1512399070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723326.1512399070000.76763.1512406680292@Atlassian.JIRA>


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

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

[~dlofthouse], right, If I authenticate using sasl-factory, no realm displayed. Is there a way to retrieve the elytron realm name in this case?


> CLI ConnectionInfo should expose security realm.
> ------------------------------------------------
>
>                 Key: WFCORE-3443
>                 URL: https://issues.jboss.org/browse/WFCORE-3443
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> This would allow to identify the authentication context the user is bound to.



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

From issues at jboss.org  Mon Dec  4 12:10:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 4 Dec 2017 12:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3443) CLI ConnectionInfo should
 expose security realm.
In-Reply-To: <JIRA.12723326.1512399070000@Atlassian.JIRA>
References: <JIRA.12723326.1512399070000@Atlassian.JIRA>
	<JIRA.12723326.1512399070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723326.1512399070000.76808.1512407401478@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-3443:
------------------------------------------

No Elytron realms only have a name to give us something to reference in a model, sharing this information with an end user would also not make sense.

> CLI ConnectionInfo should expose security realm.
> ------------------------------------------------
>
>                 Key: WFCORE-3443
>                 URL: https://issues.jboss.org/browse/WFCORE-3443
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> This would allow to identify the authentication context the user is bound to.



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

From issues at jboss.org  Mon Dec  4 12:13:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 4 Dec 2017 12:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9593) Add clustering externalizers
 for InetAddress and InetSocketAddress
In-Reply-To: <JIRA.12723366.1512407521000@Atlassian.JIRA>
References: <JIRA.12723366.1512407521000@Atlassian.JIRA>
	<JIRA.12723366.1512407521264@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723366.1512407521000.76833.1512407580204@Atlassian.JIRA>

Paul Ferraro created WFLY-9593:
----------------------------------

             Summary: Add clustering externalizers for InetAddress and InetSocketAddress
                 Key: WFLY-9593
                 URL: https://issues.jboss.org/browse/WFLY-9593
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering
    Affects Versions: 11.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


InetAddress can be marshalled as a fixed sized array depending on whether the address is IPv4 or IPv6, which can be determined by the implementation class.
InetSocketAddress can marshal its address using the InetAddress externalizer, and its port as an unsigned short.



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

From issues at jboss.org  Mon Dec  4 12:27:01 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 4 Dec 2017 12:27:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3443) CLI ConnectionInfo should
 expose security realm.
In-Reply-To: <JIRA.12723326.1512399070000@Atlassian.JIRA>
References: <JIRA.12723326.1512399070000@Atlassian.JIRA>
	<JIRA.12723326.1512399070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723326.1512399070000.76878.1512408421045@Atlassian.JIRA>


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

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

The use case is that once you are connected you can't retrieve the source of authentication. You are user X but don't know from which realm it comes from, today you have to query the model and see that the interface you are connected to references a sasl-factory with digest + realm-name. A synthetic information would help specialy when making SASL auth configuration changes from CLI.

> CLI ConnectionInfo should expose security realm.
> ------------------------------------------------
>
>                 Key: WFCORE-3443
>                 URL: https://issues.jboss.org/browse/WFCORE-3443
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> This would allow to identify the authentication context the user is bound to.



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

From issues at jboss.org  Mon Dec  4 13:05:00 2017
From: issues at jboss.org (Marcus Handte (JIRA))
Date: Mon, 4 Dec 2017 13:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9592) Arrays in Method Parameters
 are causing EJBAccessException for @PermitAll Methods
In-Reply-To: <JIRA.12723297.1512393345000@Atlassian.JIRA>
References: <JIRA.12723297.1512393345000@Atlassian.JIRA>
	<JIRA.12723297.1512393345000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723297.1512393345000.76973.1512410700289@Atlassian.JIRA>


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

Marcus Handte commented on WFLY-9592:
-------------------------------------

What's the point in asking me to file another bug, if it is closed immediately as outdated? Nevermind.

> Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-9592
>                 URL: https://issues.jboss.org/browse/WFLY-9592
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test
>            Reporter: Marcus Handte
>            Priority: Minor
>
> EJB methods with array parameters are causing EJBAccessExceptions when they are annotated with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see WFLY-1658). But it seems to be present again in 10.1.0.Final.
> For my own use case, this is not a problem since I can simply change the method signatures to use lists instead of arrays. However, I can imagine that this could be a more significant problem for people trying to run existing code that they do not want to (or cannot) touch.



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

From issues at jboss.org  Mon Dec  4 13:11:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 4 Dec 2017 13:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3443) CLI ConnectionInfo should
 expose security realm.
In-Reply-To: <JIRA.12723326.1512399070000@Atlassian.JIRA>
References: <JIRA.12723326.1512399070000@Atlassian.JIRA>
	<JIRA.12723326.1512399070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723326.1512399070000.76999.1512411060784@Atlassian.JIRA>


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

Darran Lofthouse commented on WFCORE-3443:
------------------------------------------

Until we know what we really want to expose I don't think we should be adding anything else - the names are arbitrary internal names.  Even the notion of a realm name is now something really specific to a specific authentication mechanism.

> CLI ConnectionInfo should expose security realm.
> ------------------------------------------------
>
>                 Key: WFCORE-3443
>                 URL: https://issues.jboss.org/browse/WFCORE-3443
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> This would allow to identify the authentication context the user is bound to.



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

From issues at jboss.org  Mon Dec  4 13:17:00 2017
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 4 Dec 2017 13:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1458)
 SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues
 fails on IBM JDK
In-Reply-To: <JIRA.12723253.1512380464000@Atlassian.JIRA>
References: <JIRA.12723253.1512380464000@Atlassian.JIRA>
	<JIRA.12723253.1512380464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723253.1512380464000.77012.1512411420198@Atlassian.JIRA>


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

Farah Juma commented on ELY-1458:
---------------------------------

[~mchoma] Thanks for catching this. The Authority Information Access extension's OCSP URI must have both a scheme and a scheme-specific part (as mentioned in the GeneralName definition in RFC 3280). However, the test was erroneously specifying just "ocsp:uri:10.20.30.40:8080". Since the scheme was missing, IBM JDK was considering this extension to be invalid when attempting to parse it. I've submitted the following PR to fix the test and also ensure that we check the URI name is valid when attempting to create a GeneralName.URIName:

https://github.com/wildfly-security/wildfly-elytron/pull/1043

> SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues fails on IBM JDK
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-1458
>                 URL: https://issues.jboss.org/browse/ELY-1458
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Certificate Authority
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Assignee: Farah Juma
>
> With IBM java
> {noformat}
> java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> {noformat}
> run test
> {noformat}
>  mvn test -Dtest=SelfSignedX509CertificateAndSigningKeyTest
> [INFO] Running org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.372 s <<< FAILURE! - in org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] testSelfSignedCertificateWithStringExtensionValues(org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest)  Time elapsed: 0.274 s  <<< FAILURE!
> java.lang.AssertionError
> 	at org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues(SelfSignedX509CertificateAndSigningKeyTest.java:197)
> {noformat}
> This is test line failing
> {code:java|title=SelfSignedX509CertificateAndSigningKeyTest.java}
>         byte[] authorityInfoAccessExtension = certificate.getExtensionValue(X500.OID_PE_AUTHORITY_INFO_ACCESS);
>         assertNotNull(authorityInfoAccessExtension);
> {code}



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

From issues at jboss.org  Mon Dec  4 13:28:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 4 Dec 2017 13:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3443) CLI ConnectionInfo should
 expose security realm.
In-Reply-To: <JIRA.12723326.1512399070000@Atlassian.JIRA>
References: <JIRA.12723326.1512399070000@Atlassian.JIRA>
	<JIRA.12723326.1512399070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723326.1512399070000.77089.1512412080300@Atlassian.JIRA>


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

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

I understand, getting a description (open, unspecified) of the kind of authentication in place for the current connection would be enough for a CLI user. 

> CLI ConnectionInfo should expose security realm.
> ------------------------------------------------
>
>                 Key: WFCORE-3443
>                 URL: https://issues.jboss.org/browse/WFCORE-3443
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> This would allow to identify the authentication context the user is bound to.



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

From issues at jboss.org  Mon Dec  4 13:30:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 4 Dec 2017 13:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3443) CLI ConnectionInfo should
 expose information on authentication in use
In-Reply-To: <JIRA.12723326.1512399070000@Atlassian.JIRA>
References: <JIRA.12723326.1512399070000@Atlassian.JIRA>
	<JIRA.12723326.1512399070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723326.1512399070000.77102.1512412200215@Atlassian.JIRA>


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

Jean-Francois Denise updated WFCORE-3443:
-----------------------------------------
    Summary: CLI ConnectionInfo should expose information on authentication in use  (was: CLI ConnectionInfo should expose security realm.)


> CLI ConnectionInfo should expose information on authentication in use
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-3443
>                 URL: https://issues.jboss.org/browse/WFCORE-3443
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> This would allow to identify the authentication context the user is bound to.



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

From issues at jboss.org  Mon Dec  4 15:22:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Mon, 4 Dec 2017 15:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-211) Jenkins CI Plugin -
 Release of version 1.5.0 of the Red Hat CI Plugin
In-Reply-To: <JIRA.12723384.1512418888000@Atlassian.JIRA>
References: <JIRA.12723384.1512418888000@Atlassian.JIRA>
	<JIRA.12723384.1512418888242@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723384.1512418888000.77529.1512418920208@Atlassian.JIRA>

Matt Mahoney created HAWKULARQE-211:
---------------------------------------

             Summary: Jenkins CI Plugin - Release of version 1.5.0 of the Red Hat CI Plugin
                 Key: HAWKULARQE-211
                 URL: https://issues.jboss.org/browse/HAWKULARQE-211
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Matt Mahoney
            Assignee: Michael Foley



Background:

Release of version 1.5.0 of the Red Hat CI Plugin changes from using the existing CI message bus to using the IT-supported Unified Message Bus (UMB). This document details the steps needed to make the conversion happen seamlessly in Jenkins jobs.

Doc Link: https://docs.engineering.redhat.com/display/CentralCI/UMB+Migration





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

From issues at jboss.org  Mon Dec  4 15:24:00 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Mon, 4 Dec 2017 15:24: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.77566.1512419040868@Atlassian.JIRA>


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

Liz Clayton updated DROOLS-2154:
--------------------------------
    Sprint: 2017 Week 49-50


> 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
>
> *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.
> *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  Mon Dec  4 15:25:00 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Mon, 4 Dec 2017 15:25: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.77572.1512419100602@Atlassian.JIRA>


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

Liz Clayton 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  (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)


> 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.5.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 Dec  4 15:45:01 2017
From: issues at jboss.org (Amy Glass (JIRA))
Date: Mon, 4 Dec 2017 15:45:01 -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.77702.1512420301922@Atlassian.JIRA>


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

Amy Glass updated DROOLS-2154:
------------------------------
    Labels: UX UXTeam  (was: UX)


> 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.
> *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  Mon Dec  4 15:51:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 4 Dec 2017 15:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1458)
 SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues
 fails on IBM JDK
In-Reply-To: <JIRA.12723253.1512380464000@Atlassian.JIRA>
References: <JIRA.12723253.1512380464000@Atlassian.JIRA>
	<JIRA.12723253.1512380464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723253.1512380464000.77830.1512420660094@Atlassian.JIRA>


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

Martin Choma commented on ELY-1458:
-----------------------------------

[~fjuma] thank you very much for fast fix and for detailed clarification!

> SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues fails on IBM JDK
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-1458
>                 URL: https://issues.jboss.org/browse/ELY-1458
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Certificate Authority
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Assignee: Farah Juma
>
> With IBM java
> {noformat}
> java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> {noformat}
> run test
> {noformat}
>  mvn test -Dtest=SelfSignedX509CertificateAndSigningKeyTest
> [INFO] Running org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.372 s <<< FAILURE! - in org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] testSelfSignedCertificateWithStringExtensionValues(org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest)  Time elapsed: 0.274 s  <<< FAILURE!
> java.lang.AssertionError
> 	at org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues(SelfSignedX509CertificateAndSigningKeyTest.java:197)
> {noformat}
> This is test line failing
> {code:java|title=SelfSignedX509CertificateAndSigningKeyTest.java}
>         byte[] authorityInfoAccessExtension = certificate.getExtensionValue(X500.OID_PE_AUTHORITY_INFO_ACCESS);
>         assertNotNull(authorityInfoAccessExtension);
> {code}



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

From issues at jboss.org  Mon Dec  4 16:11:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 4 Dec 2017 16:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.78050.1512421860328@Atlassian.JIRA>


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

Martin Choma commented on ELY-1455:
-----------------------------------

[~lagoria], would you mind provide war (as simple as possible) which will reproduce the problem?

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: 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  Mon Dec  4 16:35:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 4 Dec 2017 16:35: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.78228.1512423300112@Atlassian.JIRA>


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

Jozef Marko closed DROOLS-2007.
-------------------------------
    Resolution: Rejected


> [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 Dec  4 16:39:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Mon, 4 Dec 2017 16:39: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.78243.1512423540760@Atlassian.JIRA>


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

Michael Anstis 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  (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)


> 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.5.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 Dec  4 16:42:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 4 Dec 2017 16:42: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.78255.1512423720102@Atlassian.JIRA>


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

Jozef Marko reopened DROOLS-2007:
---------------------------------


> [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 Dec  4 16:47:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 4 Dec 2017 16:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2136) Remove not used mvn
	dependencies
In-Reply-To: <JIRA.12721241.1510787234000@Atlassian.JIRA>
References: <JIRA.12721241.1510787234000@Atlassian.JIRA>
	<JIRA.12721241.1510787234000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721241.1510787234000.78263.1512424020160@Atlassian.JIRA>


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

Jozef Marko closed DROOLS-2136.
-------------------------------
    Resolution: Rejected


> Remove not used mvn dependencies
> --------------------------------
>
>                 Key: DROOLS-2136
>                 URL: https://issues.jboss.org/browse/DROOLS-2136
>             Project: Drools
>          Issue Type: Task
>    Affects Versions: 7.4.1.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>
> In the drools-wb repository, remove all mvn dependencies that 
> {code:mvn}
> mvn dependency:analyze
> {code}
> marks as declared but not used



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

From issues at jboss.org  Mon Dec  4 17:25:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 4 Dec 2017 17:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9592) Arrays in Method Parameters
 are causing EJBAccessException for @PermitAll Methods
In-Reply-To: <JIRA.12723297.1512393345000@Atlassian.JIRA>
References: <JIRA.12723297.1512393345000@Atlassian.JIRA>
	<JIRA.12723297.1512393345000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723297.1512393345000.78298.1512426300467@Atlassian.JIRA>


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

David Lloyd reopened WFLY-9592:
-------------------------------


[~ctomc], I do not believe that this code is part of or is affected by Elytron.  I think that this regression was possibly re-introduced here:

https://github.com/dmlloyd/wildfly/commit/d7675fb0b19d3d22978e79954f441eeefd74a3b2

This commit was merged before the 10.0.0.Beta1 tag.  I think the better way to handle this is to say: would it be possible to give this a try on WildFly 11 to ensure that it is still valid?

> Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-9592
>                 URL: https://issues.jboss.org/browse/WFLY-9592
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test
>            Reporter: Marcus Handte
>            Priority: Minor
>
> EJB methods with array parameters are causing EJBAccessExceptions when they are annotated with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see WFLY-1658). But it seems to be present again in 10.1.0.Final.
> For my own use case, this is not a problem since I can simply change the method signatures to use lists instead of arrays. However, I can imagine that this could be a more significant problem for people trying to run existing code that they do not want to (or cannot) touch.



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

From issues at jboss.org  Mon Dec  4 18:58:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 4 Dec 2017 18:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3446) Upgrade JBoss Modules to
	1.6.2.Final
In-Reply-To: <JIRA.12723414.1512431854000@Atlassian.JIRA>
References: <JIRA.12723414.1512431854000@Atlassian.JIRA>
	<JIRA.12723414.1512431854531@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723414.1512431854000.78427.1512431880110@Atlassian.JIRA>

David Lloyd created WFCORE-3446:
-----------------------------------

             Summary: Upgrade JBoss Modules to 1.6.2.Final
                 Key: WFCORE-3446
                 URL: https://issues.jboss.org/browse/WFCORE-3446
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Modules
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 3.0.2.Final, 4.0.0.Alpha1






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

From issues at jboss.org  Tue Dec  5 03:11:00 2017
From: issues at jboss.org (Marcus Handte (JIRA))
Date: Tue, 5 Dec 2017 03:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9592) Arrays in Method Parameters
 are causing EJBAccessException for @PermitAll Methods
In-Reply-To: <JIRA.12723297.1512393345000@Atlassian.JIRA>
References: <JIRA.12723297.1512393345000@Atlassian.JIRA>
	<JIRA.12723297.1512393345000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723297.1512393345000.78830.1512461460178@Atlassian.JIRA>


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

Marcus Handte commented on WFLY-9592:
-------------------------------------

Ok, I have done some more testing with Wildfly-11.0.0.Final and again with Wildfly-10.1.0.Final just to double check that I am not making this up. You were right, Wildfly-11.0.0.Final does not have the problem with arrays anymore. On Wildfly-10.1.0.Final I am certain that the problem is solely caused by having an array in the parameter list of an accessible (and @PermitAll) session bean method:

java.lang.AssertionError: Should not receive exception. expected null, but was:<javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public com.maptology.api.user.User com.maptology.service.session.UserSessionBean.registerUser(com.maptology.api.user.UserRegistration,com.maptology.api.access.Roles[],long) throws com.maptology.service.entity.EntityConflictException of bean: UserSessionBean is not allowed>
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotNull(Assert.java:755)
	at org.junit.Assert.assertNull(Assert.java:737)
	at com.maptology.service.test.session.UserSessionTest.testRegisterAndEmailVerify(UserSessionTest.java:119)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

If I change Roles[] to List<Roles>, everything works as expected (meaning that I do not get an EJBAccessException anymore9.

> Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-9592
>                 URL: https://issues.jboss.org/browse/WFLY-9592
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test
>            Reporter: Marcus Handte
>            Priority: Minor
>
> EJB methods with array parameters are causing EJBAccessExceptions when they are annotated with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see WFLY-1658). But it seems to be present again in 10.1.0.Final.
> For my own use case, this is not a problem since I can simply change the method signatures to use lists instead of arrays. However, I can imagine that this could be a more significant problem for people trying to run existing code that they do not want to (or cannot) touch.



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

From issues at jboss.org  Tue Dec  5 04:20:00 2017
From: issues at jboss.org (Herve Remisio (JIRA))
Date: Tue, 5 Dec 2017 04:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2162) Error evaluating constraint
In-Reply-To: <JIRA.12723281.1512388250000@Atlassian.JIRA>
References: <JIRA.12723281.1512388250000@Atlassian.JIRA>
	<JIRA.12723281.1512388250000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723281.1512388250000.79220.1512465600710@Atlassian.JIRA>


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

Herve Remisio closed DROOLS-2162.
---------------------------------
    Release Notes Text: 
The issue was happening because we need to check if the attribute is NULL first.
Maybe the exception should be more clear. That would help to understand that the issue is a simple NPE.
            Resolution: Rejected


> Error evaluating constraint
> ---------------------------
>
>                 Key: DROOLS-2162
>                 URL: https://issues.jboss.org/browse/DROOLS-2162
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.4.1.Final
>            Reporter: Herve Remisio
>            Assignee: Mario Fusco
>            Priority: Blocker
>         Attachments: 2017-12-04_12-33-29.png
>
>
> We detected a very strange behavior when processing Rules that contain expressions like "...startsWith(..".
>  !2017-12-04_12-33-29.png|thumbnail! 
> Sometimes this error disappears when we simply re-upload the Rule file and it gets recompiled.



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

From issues at jboss.org  Tue Dec  5 04:33:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 5 Dec 2017 04:33: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.79274.1512466380189@Atlassian.JIRA>


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

RH Bugzilla Integration commented on WFLY-9509:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1508105|https://bugzilla.redhat.com/show_bug.cgi?id=1508105] from POST to MODIFIED

> 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  Tue Dec  5 04:48:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 04:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-728) The map backing
 SimpleMapBackedSecurityRealm should be an identity map not a password map.
In-Reply-To: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.79330.1512467280165@Atlassian.JIRA>


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

Jan Kalina commented on ELY-728:
--------------------------------

So the realm should be backed by {{Map<String, SimpleMapRealmIdentity>}} instead of {{Map<String, SimpleRealmEntry>}} and creating identities on obtaining - what is the point?
The realm can be used without stored credentials already now, or not?

> The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map.
> ------------------------------------------------------------------------------------------
>
>                 Key: ELY-728
>                 URL: https://issues.jboss.org/browse/ELY-728
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>
> This realm is useful in cases where we need an identity to exist where the mechanism has performed validation without requiring access to credentials.



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

From issues at jboss.org  Tue Dec  5 04:51:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 04:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1448) API Compatibility for
 org.wildfly.security.mechanism.MechanismUtil
In-Reply-To: <JIRA.12721453.1510941462000@Atlassian.JIRA>
References: <JIRA.12721453.1510941462000@Atlassian.JIRA>
	<JIRA.12721453.1510941462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721453.1510941462000.79341.1512467460231@Atlassian.JIRA>


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

Jan Kalina commented on ELY-1448:
---------------------------------

The API breaking is already handled by ELY-1452 - this issue should aim the class deprecating/moving into private package.

> API Compatibility for org.wildfly.security.mechanism.MechanismUtil
> ------------------------------------------------------------------
>
>                 Key: ELY-1448
>                 URL: https://issues.jboss.org/browse/ELY-1448
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.2.0.Beta11
>
>
> Backwards compatibility has been broken on the public handleCallbacks methods so this needs to be fixed.
> However this class should not really be a public API, it has been picked up in the package as we have the AuthenticationMechanismException which does need to be public.
> The entire class should be deprecated and the impl moved to a private package.



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

From issues at jboss.org  Tue Dec  5 04:55:00 2017
From: issues at jboss.org (SATISH POKALWAR (JIRA))
Date: Tue, 5 Dec 2017 04:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4947) Upgrade to Undertow
	1.1.8.Final
In-Reply-To: <JIRA.12578332.1437082707000@Atlassian.JIRA>
References: <JIRA.12578332.1437082707000@Atlassian.JIRA>
	<JIRA.12578332.1437082707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578332.1437082707000.79357.1512467700840@Atlassian.JIRA>


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

SATISH POKALWAR commented on WFLY-4947:
---------------------------------------

Hi Team ,
Is it possible for URL re-writing through standalone-full.xml file like we used to do in jboss 6.4

> Upgrade to Undertow 1.1.8.Final
> -------------------------------
>
>                 Key: WFLY-4947
>                 URL: https://issues.jboss.org/browse/WFLY-4947
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web (Undertow)
>            Reporter: Jason Greene
>            Assignee: Stuart Douglas
>             Fix For: 8.2.1.Final
>
>




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

From issues at jboss.org  Tue Dec  5 04:59:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 04:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1448) API Compatibility for
 org.wildfly.security.mechanism.MechanismUtil
In-Reply-To: <JIRA.12721453.1510941462000@Atlassian.JIRA>
References: <JIRA.12721453.1510941462000@Atlassian.JIRA>
	<JIRA.12721453.1510941462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721453.1510941462000.79393.1512467940433@Atlassian.JIRA>


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

Jan Kalina reassigned ELY-1448:
-------------------------------

    Assignee: Jan Kalina


> API Compatibility for org.wildfly.security.mechanism.MechanismUtil
> ------------------------------------------------------------------
>
>                 Key: ELY-1448
>                 URL: https://issues.jboss.org/browse/ELY-1448
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 1.2.0.Beta11
>
>
> Backwards compatibility has been broken on the public handleCallbacks methods so this needs to be fixed.
> However this class should not really be a public API, it has been picked up in the package as we have the AuthenticationMechanismException which does need to be public.
> The entire class should be deprecated and the impl moved to a private package.



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

From issues at jboss.org  Tue Dec  5 05:39:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 5 Dec 2017 05:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-728) The map backing
 SimpleMapBackedSecurityRealm should be an identity map not a password map.
In-Reply-To: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.79484.1512470340187@Atlassian.JIRA>


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

Darran Lofthouse commented on ELY-728:
--------------------------------------

This one was just a name change of the methods to set the map from 'setPasswordMap' to 'setIdentityMap' - but now as we have to maintain compatibility we would need to add new methods and deprecate the old ones.

> The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map.
> ------------------------------------------------------------------------------------------
>
>                 Key: ELY-728
>                 URL: https://issues.jboss.org/browse/ELY-728
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>
> This realm is useful in cases where we need an identity to exist where the mechanism has performed validation without requiring access to credentials.



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

From issues at jboss.org  Tue Dec  5 05:43:01 2017
From: issues at jboss.org (Prachi Yadav (JIRA))
Date: Tue, 5 Dec 2017 05:43:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-207) Define set of acceptance
	tests
In-Reply-To: <JIRA.12723347.1512402747000@Atlassian.JIRA>
References: <JIRA.12723347.1512402747000@Atlassian.JIRA>
	<JIRA.12723347.1512402747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723347.1512402747000.79515.1512470581123@Atlassian.JIRA>


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

Prachi Yadav reassigned HAWKULARQE-207:
---------------------------------------

    Assignee: Prachi Yadav  (was: Michael Foley)


> Define set of acceptance tests
> ------------------------------
>
>                 Key: HAWKULARQE-207
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-207
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Filip Brychta
>            Assignee: Prachi Yadav
>            Priority: Blocker
>
> We need a set of cases which are considered to be "must work" which will be run every time before a release.
> Example from JON:
> - ssl configuration was not part of such suite and because of that one ugly issue was missed which resulted in unreachable agents after upgrade and critical hot-fix
> Following should be done:
> * define those cases for each area
> * check that those cases are created in polarion
> * set the highest possible severity for those cases
> * define test run which will contain all those cases for each release
> * automate as much as possible
> * regularly check and update the suite with new features



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

From issues at jboss.org  Tue Dec  5 05:46:00 2017
From: issues at jboss.org (SATISH POKALWAR (JIRA))
Date: Tue, 5 Dec 2017 05:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9594) url rewriting doesnt work in
	wildfly 8.2.1
In-Reply-To: <JIRA.12723458.1512470701000@Atlassian.JIRA>
References: <JIRA.12723458.1512470701000@Atlassian.JIRA>
	<JIRA.12723458.1512470701487@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723458.1512470701000.79529.1512470760197@Atlassian.JIRA>

SATISH POKALWAR created WFLY-9594:
-------------------------------------

             Summary: url rewriting doesnt work in wildfly 8.2.1
                 Key: WFLY-9594
                 URL: https://issues.jboss.org/browse/WFLY-9594
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.2.1.Final
            Reporter: SATISH POKALWAR
            Assignee: Stuart Douglas


I have an application running on wildfly 8.2.1 which is upgraded from jboss 6.4. for URL rewriting in jboss 6.4 , we have virtual server section in standlone-full.xml however to do the same on wildfly 8.2.1 its been suggested to write the rule in undertow-handlers.conf and put the same in WEB-INF directory ,however that is not working.Basically i want to rewrite http://ip_address/a and http://ip_address/b to http://ip_address/c , to do the same i have written below rule in undertow-handlers.conf it is not working, regex['^/a/$'] -> rewrite['/c/$1']. Can anyone tell if am doing anything wrong , similiar rule used to work in JBOSS 6.4 



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

From issues at jboss.org  Tue Dec  5 06:29:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 5 Dec 2017 06:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-83) Create test cases for
 hawkular-wildfly-agent-installer.jar
In-Reply-To: <JIRA.12685653.1491229337000@Atlassian.JIRA>
References: <JIRA.12685653.1491229337000@Atlassian.JIRA>
	<JIRA.12685653.1491229337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12685653.1491229337000.79739.1512473340257@Atlassian.JIRA>


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

Hayk Hovsepyan resolved HAWKULARQE-83.
--------------------------------------
    Resolution: Done


Hawkular Wildfly agent will be gone after TP3 release.
Task is outdated.

> Create test cases for hawkular-wildfly-agent-installer.jar
> ----------------------------------------------------------
>
>                 Key: HAWKULARQE-83
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-83
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Filip Brychta
>            Assignee: Hayk Hovsepyan
>
> hawkular-wildfly-agent-installer.jar has following options:
> Options:
>   -D, --D                              Defines system properties to set
>   --installer-config                   Installer .properties configuration file
>   --encryption-key                     If specified, this is used to decode the properties that were encrypted. If you do not provide a value with the option, you will be prompted for one.
>   --encryption-salt                    The salt used for generating the key. Recommended, if encryption is used. If not specified, the same value as the key will be used.
>   --enabled                            Indicates if the agent should be enabled at startup
>   --config-only                        Skip installation of the add-ons modules, and only update the server config (e.g. standalone.xml).
>   --target-location                    Target home directory of the application server where the agent is to be installed
>   --module-dist                        Hawkular WildFly Agent Module distribution zip file - can be a file path or URL
>   --server-url                         Server URL where the agent will send its monitoring data. This is a string to be set as the storage adapter URL.
>   --download-server-url                Server URL from which the installer will download content it may need. If not specified and the installer needs to download something then --server-url will be used.
>   --target-config                      The target configuration file to write to. Can be either absolute path or relative to target-location
>   --subsystem-snippet                  Customized subsystem XML content that overrides the default subsystem configuration
>   --managed-server-name                The agent will use this name to refer to the server where it is deployed and locally managing.
>   --feed-id                            The feed ID that the agent will use to identify its data.
>   --tenant-id                          The tenant ID that the agent will ask to be used. Usually only used when in metrics-only mode.
>   --metrics-only                       If true, the agent will be configured to run in metrics-only mode (inventory will not be stored and no websocket connection to a Hawkular Server will be made.) If true, you must specify a tenant-id.
>   --managed-server-resource-type-sets  If true, the agent will be configured to monitor these resource type sets. If not provided, a default set will be used based on the type of application server where the agent is being installed into (standalone or domain).
>   --keystore-path                      Keystore file. Required when server-url protocol is https
>   --keystore-password                  Keystore password. When server-url protocol is https and this option is not passed, installer will ask for password
>   --username                           User the agent will use when connecting to Hawkular Server.
>   --password                           Credentials agent will use when connecting to Hawkular Server.
> We need to create test cases to cover that



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

From issues at jboss.org  Tue Dec  5 06:37:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 5 Dec 2017 06:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-201) Middleware Events are
 triggered automaticaly
In-Reply-To: <JIRA.12719018.1509557104000@Atlassian.JIRA>
References: <JIRA.12719018.1509557104000@Atlassian.JIRA>
	<JIRA.12719018.1509557104000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719018.1509557104000.79773.1512473820770@Atlassian.JIRA>


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

Hayk Hovsepyan resolved HAWKULARQE-201.
---------------------------------------
    Resolution: Done


Testcase is executed as of TP3 DR3 and 5.9.0.11.20171127204214_e316988

> Middleware Events are triggered automaticaly 
> ---------------------------------------------
>
>                 Key: HAWKULARQE-201
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-201
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>              Labels: 4.6
>




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

From issues at jboss.org  Tue Dec  5 06:39:02 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:02 -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.79796.1512473942079@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-2149:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> 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 Dec  5 06:39:02 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:02 -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.79800.1512473942278@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-2083:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> [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 Dec  5 06:39:02 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:02 -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.79805.1512473942450@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-2001:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> 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 Dec  5 06:39:02 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:02 -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.79811.1512473942607@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1946:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> 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 Dec  5 06:39:02 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1930) [Guided Rule] Stabilize
	rules tests IE
In-Reply-To: <JIRA.12706380.1502110195000@Atlassian.JIRA>
References: <JIRA.12706380.1502110195000@Atlassian.JIRA>
	<JIRA.12706380.1502110195000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12706380.1502110195000.79814.1512473942673@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1930:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> [Guided Rule] Stabilize rules tests IE
> --------------------------------------
>
>                 Key: DROOLS-1930
>                 URL: https://issues.jboss.org/browse/DROOLS-1930
>             Project: Drools
>          Issue Type: Task
>          Components: Guided Rule Editor
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>             Fix For: 7.6.0.Final
>
>
> According to [test results|https://bxms-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/BxMS/job/BxMS-7.x-upstream/job/business-central/job/rules/job/bpms-upstream-7.0-blessed-business-central-rules-ie/lastSuccessfulBuild/artifact/tests/test-kie-wb/target/site/new-report.html] stabilize rules tests for IE.



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

From issues at jboss.org  Tue Dec  5 06:39:02 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1929) [Guided Rule] Stabilize
	dtables tests IE
In-Reply-To: <JIRA.12708252.1503390912000@Atlassian.JIRA>
References: <JIRA.12708252.1503390912000@Atlassian.JIRA>
	<JIRA.12708252.1503390912000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12708252.1503390912000.79817.1512473942742@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1929:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> [Guided Rule] Stabilize dtables tests IE
> ----------------------------------------
>
>                 Key: DROOLS-1929
>                 URL: https://issues.jboss.org/browse/DROOLS-1929
>             Project: Drools
>          Issue Type: Task
>          Components: Guided Rule Editor
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>             Fix For: 7.6.0.Final
>
>
> According to [test results|https://bxms-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/BxMS/job/BxMS-7.x-upstream/job/business-central/job/dtables/job/bpms-upstream-7.0-blessed-business-central-dtables-ie/lastSuccessfulBuild/artifact/tests/test-kie-wb/target/site/new-report.html] stabilize dtables tests for IE.



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

From issues at jboss.org  Tue Dec  5 06:39:02 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1893) [Guided Decision Table]
 Stabilize dtables tests for IE
In-Reply-To: <JIRA.12706374.1502108963000@Atlassian.JIRA>
References: <JIRA.12706374.1502108963000@Atlassian.JIRA>
	<JIRA.12706374.1502108963000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12706374.1502108963000.79821.1512473942912@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1893:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> [Guided Decision Table] Stabilize dtables tests for IE
> ------------------------------------------------------
>
>                 Key: DROOLS-1893
>                 URL: https://issues.jboss.org/browse/DROOLS-1893
>             Project: Drools
>          Issue Type: Task
>          Components: Guided Decision Table Editor
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>             Fix For: 7.6.0.Final
>
>
> According to tests results [here|https://bxms-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/BxMS/job/BxMS-7.x-upstream/job/business-central/job/dtables/job/bpms-upstream-7.0-blessed-business-central-dtables-ie/lastSuccessfulBuild/artifact/tests/test-kie-wb/target/site/new-report.html] stabilize dtables tests for IE.



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

From issues at jboss.org  Tue Dec  5 06:39:02 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1891) Guided decision table: Add
 menu option on toolbar for "auto-expansion" of conditions
In-Reply-To: <JIRA.12448595.1317803560000@Atlassian.JIRA>
References: <JIRA.12448595.1317803560000@Atlassian.JIRA>
	<JIRA.12448595.1317803560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12448595.1317803560000.79825.1512473942989@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1891:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> Guided decision table: Add menu option on toolbar for "auto-expansion" of conditions
> ------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1891
>                 URL: https://issues.jboss.org/browse/DROOLS-1891
>             Project: Drools
>          Issue Type: Sub-task
>          Components: Guided Decision Table Editor
>    Affects Versions: 5.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>             Fix For: 7.6.0.Final
>
>
> You can elect to create an expanded decision table when using the Wizard, however it should be possible to expand from the asset editor.



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

From issues at jboss.org  Tue Dec  5 06:39:03 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1846) Allow real time
 verification of Fact's constraints in Guided Editor
In-Reply-To: <JIRA.12410433.1273521388000@Atlassian.JIRA>
References: <JIRA.12410433.1273521388000@Atlassian.JIRA>
	<JIRA.12410433.1273521388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12410433.1273521388000.79829.1512473943140@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1846:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> Allow real time verification of Fact's constraints in Guided Editor
> -------------------------------------------------------------------
>
>                 Key: DROOLS-1846
>                 URL: https://issues.jboss.org/browse/DROOLS-1846
>             Project: Drools
>          Issue Type: Feature Request
>          Components: Guided Decision Table Editor, Guided Rule Editor, Guided Template Editor
>            Reporter: Esteban Aliverti
>            Assignee: Guilherme Carreiro
>            Priority: Minor
>              Labels: guvnor, real_time, real_time_verification
>             Fix For: 7.6.0.Final
>
>
> It would be good to have real time validation of Fact's Constraints in Guvnor's Guided Editor.
> We can use the same verifier rules created by the constraints that are used right now in the "on demand" verification.



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

From issues at jboss.org  Tue Dec  5 06:39:03 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:03 -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.79834.1512473943243@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1811:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> [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 Dec  5 06:39:03 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1792) [Guided Decision Table]
 Default value of a column is not validated with the field data type
In-Reply-To: <JIRA.12669028.1483363118000@Atlassian.JIRA>
References: <JIRA.12669028.1483363118000@Atlassian.JIRA>
	<JIRA.12669028.1483363118000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669028.1483363118000.79838.1512473943370@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1792:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> [Guided Decision Table] Default value of a column is not validated with the field data type
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1792
>                 URL: https://issues.jboss.org/browse/DROOLS-1792
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.0.0.Beta5
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>              Labels: dtable_testday_preparation, qe-suggest-pre-7.0.0.Final, qe-test-day, reported-by-qe
>             Fix For: 7.6.0.Final
>
>
> During definition of a condition or an action column, user has possibility to specify 'Default value' for this column. The problem is that the default value is not validated with the field data type. In practice it means that even when the column expects only _Integer_ values (because of the field data type), the default value still can be some _String_ value. The 'Default value' inputs should be validated like particular cells of the guided decision table. In those cells the user is not able to put _String_ value into the cell where are expected only _Integer_ values.



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

From issues at jboss.org  Tue Dec  5 06:39:03 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1736) Create DMN benchmarks
In-Reply-To: <JIRA.12712325.1505826996000@Atlassian.JIRA>
References: <JIRA.12712325.1505826996000@Atlassian.JIRA>
	<JIRA.12712325.1505826996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712325.1505826996000.79841.1512473943419@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1736:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> Create DMN benchmarks
> ---------------------
>
>                 Key: DROOLS-1736
>                 URL: https://issues.jboss.org/browse/DROOLS-1736
>             Project: Drools
>          Issue Type: Task
>          Components: dmn engine
>    Affects Versions: 7.3.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Tibor Zim?nyi
>             Fix For: 7.6.0.Final
>
>
> We need to measure DMN runtime and buildtime performance. There is a repository with Drools benchmarks [1]. New benchmarks should be added there.
> [1] https://github.com/kiegroup/kie-benchmarks



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


From issues at jboss.org  Tue Dec  5 06:39:03 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1602) Support model composition
 through BKM invocation
In-Reply-To: <JIRA.12695752.1496447786000@Atlassian.JIRA>
References: <JIRA.12695752.1496447786000@Atlassian.JIRA>
	<JIRA.12695752.1496447786000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12695752.1496447786000.79844.1512473943478@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1602:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> Support model composition through BKM invocation
> ------------------------------------------------
>
>                 Key: DROOLS-1602
>                 URL: https://issues.jboss.org/browse/DROOLS-1602
>             Project: Drools
>          Issue Type: Sub-task
>          Components: dmn engine
>    Affects Versions: 7.1.0.Beta2
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 7.6.0.Final
>
>         Attachments: Screenshot 2017-06-02 19.56.31.png
>
>
> Signavio supports model composition through BKM integration. In order to integrate with them, we will need to add this feature to the runtime.
> See screenshot.



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

From issues at jboss.org  Tue Dec  5 06:39:03 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1601) Support constraints on List
 inputs in DT cells
In-Reply-To: <JIRA.12695751.1496447634000@Atlassian.JIRA>
References: <JIRA.12695751.1496447634000@Atlassian.JIRA>
	<JIRA.12695751.1496447634000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12695751.1496447634000.79847.1512473943533@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1601:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> Support constraints on List inputs in DT cells
> ----------------------------------------------
>
>                 Key: DROOLS-1601
>                 URL: https://issues.jboss.org/browse/DROOLS-1601
>             Project: Drools
>          Issue Type: Sub-task
>          Components: dmn engine
>    Affects Versions: 7.1.0.Beta2
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 7.6.0.Final
>
>
> Make sure the unary tests in the decision tables work fine with list inputs. This ticket might require no changes on our side, but we should at least add a couple tests to avoid regressions in the future.



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

From issues at jboss.org  Tue Dec  5 06:39:03 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1600) Support character ? for
 interpolation in values in a DT cell
In-Reply-To: <JIRA.12695750.1496447443000@Atlassian.JIRA>
References: <JIRA.12695750.1496447443000@Atlassian.JIRA>
	<JIRA.12695750.1496447443000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12695750.1496447443000.79850.1512473943621@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1600:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> Support character ? for interpolation in values in a DT cell
> ------------------------------------------------------------
>
>                 Key: DROOLS-1600
>                 URL: https://issues.jboss.org/browse/DROOLS-1600
>             Project: Drools
>          Issue Type: Sub-task
>          Components: dmn engine
>    Affects Versions: 7.1.0.Beta2
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 7.6.0.Final
>
>         Attachments: Screenshot 2017-06-02 19.50.40.png
>
>
> Signavio uses the character ? to interpolate the expression value into decision table cells. E.g.:
> =(1 - Discount) * ?
> In the above example, '?' is replaced my the result of the decision table input expression. 
> See attached screenshot. 



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

From issues at jboss.org  Tue Dec  5 06:39:03 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1597) Implement profile for
 integration with Signavio's DMN modeler
In-Reply-To: <JIRA.12695747.1496446212000@Atlassian.JIRA>
References: <JIRA.12695747.1496446212000@Atlassian.JIRA>
	<JIRA.12695747.1496446212000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12695747.1496446212000.79853.1512473943677@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1597:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> Implement profile for integration with Signavio's DMN modeler
> -------------------------------------------------------------
>
>                 Key: DROOLS-1597
>                 URL: https://issues.jboss.org/browse/DROOLS-1597
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>    Affects Versions: 7.1.0.Beta2
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 7.6.0.Final
>
>
> Signavio implements a number of extensions to the DMN standard. As they are a Red Hat partner, we will need to implement a profile in the runtime engine that enables and supports those extensions.
> A short list of extensions is as follows. Details will be added to individual tickets:
> * Support additional FEEL functions and alternate names for existing functions
> * Support the Multi Instance Decision node
> * Support character '?' for interpolation of values in a DT cell
> * Support constraints on List inputs in DT cells
> * Support model composition through BKMs



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

From issues at jboss.org  Tue Dec  5 06:39:03 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 5 Dec 2017 06:39:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1553) Write documentation for the
 DMN and FEEL components
In-Reply-To: <JIRA.12690982.1494094461000@Atlassian.JIRA>
References: <JIRA.12690982.1494094461000@Atlassian.JIRA>
	<JIRA.12690982.1494094461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12690982.1494094461000.79856.1512473943744@Atlassian.JIRA>


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

Michael Biarnes Kiefer updated DROOLS-1553:
-------------------------------------------
    Fix Version/s: 7.6.0.Final
                       (was: 7.5.0.Final)


> Write documentation for the DMN and FEEL components
> ---------------------------------------------------
>
>                 Key: DROOLS-1553
>                 URL: https://issues.jboss.org/browse/DROOLS-1553
>             Project: Drools
>          Issue Type: Task
>          Components: dmn engine
>    Affects Versions: 7.0.0.CR3
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 7.6.0.Final
>
>
> Write the documentation for both FEEL and DMN engines.



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

From issues at jboss.org  Tue Dec  5 06:54:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 5 Dec 2017 06:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9595) Incorrect Journal filesize
 calculation where specified size is lest that the block size when using AIO
In-Reply-To: <JIRA.12723500.1512474789000@Atlassian.JIRA>
References: <JIRA.12723500.1512474789000@Atlassian.JIRA>
	<JIRA.12723500.1512474789995@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723500.1512474789000.80141.1512474840736@Atlassian.JIRA>

Darran Lofthouse created WFLY-9595:
--------------------------------------

             Summary: Incorrect Journal filesize calculation where specified size is lest that the block size when using AIO
                 Key: WFLY-9595
                 URL: https://issues.jboss.org/browse/WFLY-9595
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 11.0.0.Final
            Reporter: Darran Lofthouse
            Assignee: Jeff Mesnil
             Fix For: 12.0.0.Alpha1


This issue was discovered as a side effect of: -

https://github.com/wildfly/wildfly/commit/df9e16241207ebc412ddd16c790c4b7fee31a5c0

This change updated the size to be 1024 for the tests as a large file was not necessary.  For continuous integration the agents have a blocksize of 512 so as the configured size is a multiple of the blocksize this was fine.

However running the test 'org.jboss.as.test.integration.domain.ExpressionSupportSmokeTestCase' on a machine with a blocksize of 4096 this test would fail as the servers would fail to boot.

After some debugging it became aparant this was the underlying error: -

{noformat}
{"jboss.messaging-activemq.default.jms.manager" => "java.lang.IllegalArgumentException: File size cannot be less than 1024 bytes
    Caused by: java.lang.IllegalArgumentException: File size cannot be less than 1024 bytes"}
{noformat}

After further debugging I have tracked it down to this class 'org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager' - I can confirm the configured value does make it to this class but it is the following block of code which then looses the value: -

{code:java}
      int fileSize = config.getJournalFileSize();
      // we need to correct the file size if its not a multiple of the alignement
      int modulus = fileSize % journalFF.getAlignment();
      if (modulus != 0) {
         int difference = modulus;
         int low = config.getJournalFileSize() - difference;
         int high = low + journalFF.getAlignment();
         fileSize = difference < journalFF.getAlignment() / 2 ? low : high;
         ActiveMQServerLogger.LOGGER.invalidJournalFileSize(config.getJournalFileSize(), fileSize, journalFF.getAlignment());
      }
      Journal localMessage = new JournalImpl(ioExecutors, fileSize, config.getJournalMinFiles(), config.getJournalPoolFiles(), config.getJournalCompactMinFiles(), config.getJournalCompactPercentage(), journalFF, "activemq-data", "amq", journalFF.getMaxIO(), 0);
{code}

The file size comes in as 1024, the default is AIO so getAlignment returns the blocksize which in this case is 4096.  So modulus and subsequently difference become 1024.

The file size and difference are both 1024 so low becomes 0, high becomes 4096.  Due to the difference being less than half the block size low is selected and the file size is set to 0.

To select a correct filesize it looks like if low is less than the alignment always select high should be an option.




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

From issues at jboss.org  Tue Dec  5 06:54:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 5 Dec 2017 06:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9595) Incorrect Journal filesize
 calculation where specified size is lest that the block size when using AIO
In-Reply-To: <JIRA.12723500.1512474790000@Atlassian.JIRA>
References: <JIRA.12723500.1512474790000@Atlassian.JIRA>
	<JIRA.12723500.1512474790000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723500.1512474790000.80149.1512474840977@Atlassian.JIRA>


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

Darran Lofthouse commented on WFLY-9595:
----------------------------------------

I am going to go and create another issue as I have a fix for the test case to avoid triggering this so this issue is just to track the calculation issue.

> Incorrect Journal filesize calculation where specified size is lest that the block size when using AIO
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9595
>                 URL: https://issues.jboss.org/browse/WFLY-9595
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 11.0.0.Final
>            Reporter: Darran Lofthouse
>            Assignee: Jeff Mesnil
>             Fix For: 12.0.0.Alpha1
>
>
> This issue was discovered as a side effect of: -
> https://github.com/wildfly/wildfly/commit/df9e16241207ebc412ddd16c790c4b7fee31a5c0
> This change updated the size to be 1024 for the tests as a large file was not necessary.  For continuous integration the agents have a blocksize of 512 so as the configured size is a multiple of the blocksize this was fine.
> However running the test 'org.jboss.as.test.integration.domain.ExpressionSupportSmokeTestCase' on a machine with a blocksize of 4096 this test would fail as the servers would fail to boot.
> After some debugging it became aparant this was the underlying error: -
> {noformat}
> {"jboss.messaging-activemq.default.jms.manager" => "java.lang.IllegalArgumentException: File size cannot be less than 1024 bytes
>     Caused by: java.lang.IllegalArgumentException: File size cannot be less than 1024 bytes"}
> {noformat}
> After further debugging I have tracked it down to this class 'org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager' - I can confirm the configured value does make it to this class but it is the following block of code which then looses the value: -
> {code:java}
>       int fileSize = config.getJournalFileSize();
>       // we need to correct the file size if its not a multiple of the alignement
>       int modulus = fileSize % journalFF.getAlignment();
>       if (modulus != 0) {
>          int difference = modulus;
>          int low = config.getJournalFileSize() - difference;
>          int high = low + journalFF.getAlignment();
>          fileSize = difference < journalFF.getAlignment() / 2 ? low : high;
>          ActiveMQServerLogger.LOGGER.invalidJournalFileSize(config.getJournalFileSize(), fileSize, journalFF.getAlignment());
>       }
>       Journal localMessage = new JournalImpl(ioExecutors, fileSize, config.getJournalMinFiles(), config.getJournalPoolFiles(), config.getJournalCompactMinFiles(), config.getJournalCompactPercentage(), journalFF, "activemq-data", "amq", journalFF.getMaxIO(), 0);
> {code}
> The file size comes in as 1024, the default is AIO so getAlignment returns the blocksize which in this case is 4096.  So modulus and subsequently difference become 1024.
> The file size and difference are both 1024 so low becomes 0, high becomes 4096.  Due to the difference being less than half the block size low is selected and the file size is set to 0.
> To select a correct filesize it looks like if low is less than the alignment always select high should be an option.



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

From issues at jboss.org  Tue Dec  5 06:57:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 5 Dec 2017 06:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9596) Update domain mode tests to
 use NIO journal type for messaging
In-Reply-To: <JIRA.12723501.1512474988000@Atlassian.JIRA>
References: <JIRA.12723501.1512474988000@Atlassian.JIRA>
	<JIRA.12723501.1512474988905@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723501.1512474988000.80169.1512475020421@Atlassian.JIRA>

Darran Lofthouse created WFLY-9596:
--------------------------------------

             Summary: Update domain mode tests to use NIO journal type for messaging
                 Key: WFLY-9596
                 URL: https://issues.jboss.org/browse/WFLY-9596
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 12.0.0.Alpha1


This is in relation to WFLY-9595 where failures are experienced on different environments in relation to the blocksize - however switching to NIO would make sense anyway.



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

From issues at jboss.org  Tue Dec  5 07:14:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 5 Dec 2017 07:14: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.1512476013193@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723502.1512476013000.80328.1512476040296@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3447:
--------------------------------------------

             Summary: 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).




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

From issues at jboss.org  Tue Dec  5 07:15:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 5 Dec 2017 07:15: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.80336.1512476100457@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).

An analysis doc, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI

  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).




> 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).
> An analysis doc, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI



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

From issues at jboss.org  Tue Dec  5 08:58:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 08:58: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.80952.1512482280400@Atlassian.JIRA>


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

Jan Kalina updated ELY-1295:
----------------------------
    Labels: ibm-java  (was: )


> 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
>              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  Tue Dec  5 08:58:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 08:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1299)
 X509EvidenceVerificationSuiteChild.testX509Auth() fails on IBM JDK
In-Reply-To: <JIRA.12703087.1500637626000@Atlassian.JIRA>
References: <JIRA.12703087.1500637626000@Atlassian.JIRA>
	<JIRA.12703087.1500637626000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703087.1500637626000.80958.1512482280601@Atlassian.JIRA>


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

Jan Kalina updated ELY-1299:
----------------------------
    Labels: ibm-java  (was: )


> X509EvidenceVerificationSuiteChild.testX509Auth() fails on IBM JDK
> ------------------------------------------------------------------
>
>                 Key: ELY-1299
>                 URL: https://issues.jboss.org/browse/ELY-1299
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>              Labels: ibm-java
>             Fix For: 1.2.0.Beta1
>
>
> {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=LdapTestSuite
> {code}
> Expected: the selected test suite passes
> Actual: {{X509EvidenceVerificationSuiteChild.testX509Auth()}} fails with the following exception:
> {code}
> java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data
> 	at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268)
> 	at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:407)
> 	at org.wildfly.security.ldap.X509EvidenceVerificationSuiteChild.loadCertificate(X509EvidenceVerificationSuiteChild.java:74)
> 	at org.wildfly.security.ldap.X509EvidenceVerificationSuiteChild.testX509Auth(X509EvidenceVerificationSuiteChild.java:65)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:61)
> 	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 message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec  5 08:58:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 08:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1458)
 SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues
 fails on IBM JDK
In-Reply-To: <JIRA.12723253.1512380464000@Atlassian.JIRA>
References: <JIRA.12723253.1512380464000@Atlassian.JIRA>
	<JIRA.12723253.1512380464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723253.1512380464000.80962.1512482280715@Atlassian.JIRA>


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

Jan Kalina updated ELY-1458:
----------------------------
    Labels: ibm-java  (was: )


> SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues fails on IBM JDK
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-1458
>                 URL: https://issues.jboss.org/browse/ELY-1458
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Certificate Authority
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Assignee: Farah Juma
>              Labels: ibm-java
>
> With IBM java
> {noformat}
> java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr4fp6-20170518_02(SR4 FP6))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170516_348050 (JIT enabled, AOT enabled)
> J9VM - R28_20170516_1905_B348050
> JIT  - tr.r14.java_20170516_348050
> GC   - R28_20170516_1905_B348050_CMPRSS
> J9CL - 20170516_348050)
> JCL - 20170516_01 based on Oracle jdk8u131-b11
> {noformat}
> run test
> {noformat}
>  mvn test -Dtest=SelfSignedX509CertificateAndSigningKeyTest
> [INFO] Running org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.372 s <<< FAILURE! - in org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest
> [ERROR] testSelfSignedCertificateWithStringExtensionValues(org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest)  Time elapsed: 0.274 s  <<< FAILURE!
> java.lang.AssertionError
> 	at org.wildfly.security.x500.cert.SelfSignedX509CertificateAndSigningKeyTest.testSelfSignedCertificateWithStringExtensionValues(SelfSignedX509CertificateAndSigningKeyTest.java:197)
> {noformat}
> This is test line failing
> {code:java|title=SelfSignedX509CertificateAndSigningKeyTest.java}
>         byte[] authorityInfoAccessExtension = certificate.getExtensionValue(X500.OID_PE_AUTHORITY_INFO_ACCESS);
>         assertNotNull(authorityInfoAccessExtension);
> {code}



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

From issues at jboss.org  Tue Dec  5 09:23:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 09:23: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.81200.1512483780510@Atlassian.JIRA>


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

Jan Kalina updated ELY-1298:
----------------------------
    Labels: ibm-java  (was: )


> GssapiCompatibilitySuiteChild fails on IBM JDK
> ----------------------------------------------
>
>                 Key: ELY-1298
>                 URL: https://issues.jboss.org/browse/ELY-1298
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>              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  Tue Dec  5 09:23:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 09:23: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.81203.1512483780563@Atlassian.JIRA>


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

Jan Kalina updated ELY-1298:
----------------------------
    Component/s: Testsuite


> 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: Peter Palaga
>              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  Tue Dec  5 09:32:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 09:32: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.81240.1512484320265@Atlassian.JIRA>


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

Jan Kalina reassigned ELY-1298:
-------------------------------

    Assignee:     (was: Peter Palaga)


> 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
>              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  Tue Dec  5 09:33:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 09:33: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.81249.1512484380449@Atlassian.JIRA>


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

Jan Kalina commented on ELY-1298:
---------------------------------

Unassigning, as Peter has mentioned he is not working on project already.

> 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
>              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  Tue Dec  5 09:53:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 09:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1300) Pem.parsePemX509Certificate()
 cannot parse files with non-PEM content
In-Reply-To: <JIRA.12703136.1500645599000@Atlassian.JIRA>
References: <JIRA.12703136.1500645599000@Atlassian.JIRA>
	<JIRA.12703136.1500645599000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703136.1500645599000.81445.1512485580368@Atlassian.JIRA>


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

Jan Kalina reassigned ELY-1300:
-------------------------------

    Assignee: Jan Kalina


> Pem.parsePemX509Certificate() cannot parse files with non-PEM content
> ---------------------------------------------------------------------
>
>                 Key: ELY-1300
>                 URL: https://issues.jboss.org/browse/ELY-1300
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>
> Add a test like this to `PemTest`:
> {code}
>     @Test
>     public void testParsePemX509Certificate01() throws Exception {
>         URL url = PemTest.class.getResource("/ca/certs/01.pem");
>         byte[] bytes = Files.readAllBytes(Paths.get(url.toURI()));
>         assertNotNull(Pem.parsePemX509Certificate(CodePointIterator.ofUtf8Bytes(bytes)));
>     }
> {code}
> Note that {{ca/certs/01.pem}} should start with non-PEM content
> {code}
> Certificate:
>     Data:
> ...
> {code}
> followed by the PEM content:
> {code}
> -----BEGIN CERTIFICATE-----
> {code}
> Run the test
> {code}
> mvn clean test -Dtest=PemTest#testParsePemX509Certificate01
> {code}
> Expected: Not quite sure if the parser should accept this. In any case, the following code works on Oracle/OpenJDK (while it does not on IBM JDK):
> {code}
>         CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
>         InputStream is = X509EvidenceVerificationSuiteChild.class.getResourceAsStream("/ca/certs/01.pem");
>         Assert.assertNotNull((X509Certificate) certificateFactory.generateCertificate(is));
> {code}
> Actual: 
> {code}
> testParsePemX509Certificate01(org.wildfly.security.util.PemTest)  Time elapsed: 0.116 sec  <<< ERROR!
> java.lang.IllegalArgumentException: ELY03010: Malformed PEM content at offset 1
> 	at org.wildfly.security.pem.Pem.parsePemContent(Pem.java:79)
> 	at org.wildfly.security.pem.Pem.parsePemX509Certificate(Pem.java:272)
> 	at org.wildfly.security.util.PemTest.testParsePemX509Certificate01(PemTest.java:57)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	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 message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec  5 10:00:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 10:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-744) Create log categories for
 mechanisms instead of prefixing messages
In-Reply-To: <JIRA.12660995.1478874999000@Atlassian.JIRA>
References: <JIRA.12660995.1478874999000@Atlassian.JIRA>
	<JIRA.12660995.1478874999000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660995.1478874999000.81486.1512486000371@Atlassian.JIRA>


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

Jan Kalina reassigned ELY-744:
------------------------------

    Assignee: Martin Mazanek  (was: Jan Kalina)


> Create log categories for mechanisms instead of prefixing messages
> ------------------------------------------------------------------
>
>                 Key: ELY-744
>                 URL: https://issues.jboss.org/browse/ELY-744
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>            Reporter: Jan Kalina
>            Assignee: Martin Mazanek
>            Priority: Minor
>             Fix For: 1.2.0.Beta10
>
>
> In log messages are often used prefixes to determine context of the message - typically name of mechanism:
> {code:java}
> log.trace("ClientCertAuthenticationMechanism: re-authentication succeed");
> {code}
> This should be replaced by standalone log categories.



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

From issues at jboss.org  Tue Dec  5 10:07:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Dec 2017 10:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-184) Wrong values for unknown
	method/class
In-Reply-To: <JIRA.12723556.1512486365000@Atlassian.JIRA>
References: <JIRA.12723556.1512486365000@Atlassian.JIRA>
	<JIRA.12723556.1512486365772@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723556.1512486365000.81515.1512486420249@Atlassian.JIRA>

David Lloyd created LOGMGR-184:
----------------------------------

             Summary: 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


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  Tue Dec  5 10:15:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 5 Dec 2017 10:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2228) ASYM_ENCRYPT: test with
 encrypt_entire_msg=true
In-Reply-To: <JIRA.12717509.1508740954000@Atlassian.JIRA>
References: <JIRA.12717509.1508740954000@Atlassian.JIRA>
	<JIRA.12717509.1508740954000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717509.1508740954000.81540.1512486900381@Atlassian.JIRA>


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

Bela Ban updated JGRP-2228:
---------------------------
    Fix Version/s: 4.0.10
                       (was: 4.0.9)


> ASYM_ENCRYPT: test with encrypt_entire_msg=true
> -----------------------------------------------
>
>                 Key: JGRP-2228
>                 URL: https://issues.jboss.org/browse/JGRP-2228
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>         Attachments: asym-encrypt.xml, asym-encrypt.xml
>
>
> * Start a few nodes with {{ASYM_ENCRYPT}} and {{encrypt_entire_msg}} set to {{true}}
> * Kill and restart a member
> * Apparently, restarting is not possible, as the new member won't be able to join the cluster
> -> Verify this is true and - if yes - fix it



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

From issues at jboss.org  Tue Dec  5 10:15:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 5 Dec 2017 10:15: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.81546.1512486900628@Atlassian.JIRA>


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

Bela Ban updated JGRP-2234:
---------------------------
    Fix Version/s: 4.0.10
                       (was: 4.0.9)


> 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 Dec  5 10:15:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 5 Dec 2017 10:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2235)
 ConcurrentModificationException when resend pending lock requests
In-Reply-To: <JIRA.12720907.1510650203000@Atlassian.JIRA>
References: <JIRA.12720907.1510650203000@Atlassian.JIRA>
	<JIRA.12720907.1510650203000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720907.1510650203000.81552.1512486900829@Atlassian.JIRA>


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

Bela Ban updated JGRP-2235:
---------------------------
    Fix Version/s: 4.0.10
                       (was: 4.0.9)


> ConcurrentModificationException when resend pending lock requests
> -----------------------------------------------------------------
>
>                 Key: JGRP-2235
>                 URL: https://issues.jboss.org/browse/JGRP-2235
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bram Klein Gunnewiek
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> While testing JGRP-2234 we saw a ConcurrentModificationException in the locking protocol in some (rare) situations:
> {noformat}
> 09:46:42.856 [jgroups-7,TEST,B] ERROR org.jgroups.protocols.pbcast.GMS - JGRP000027: failed passing message up
> java.util.ConcurrentModificationException: null
> 	at java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1630) ~[?:1.8.0_151]
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:1.8.0_151]
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_151]
> 	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) ~[?:1.8.0_151]
> 	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) ~[?:1.8.0_151]
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_151]
> 	at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) ~[?:1.8.0_151]
> 	at org.jgroups.protocols.Locking$ClientLockTable.lambda$resendPendingLockRequests$3(Locking.java:1085) ~[classes/:?]
> 	at java.util.concurrent.ConcurrentHashMap$ValuesView.forEach(ConcurrentHashMap.java:4707) ~[?:1.8.0_151]
> 	at org.jgroups.protocols.Locking$ClientLockTable.resendPendingLockRequests(Locking.java:1084) ~[classes/:?]
> 	at org.jgroups.protocols.CENTRAL_LOCK.handleView(CENTRAL_LOCK.java:147) ~[classes/:?]
> 	at org.jgroups.protocols.Locking.up(Locking.java:218) ~[classes/:?]
> 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:163) ~[classes/:?]
> 	at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:702) ~[classes/:?]
> 	at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:135) ~[classes/:?]
> 	at org.jgroups.protocols.pbcast.GMS.up(GMS.java:918) ~[classes/:?]
> 	at org.jgroups.stack.Protocol.up(Protocol.java:364) [classes/:?]
> 	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:293) [classes/:?]
> 	at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:428) [classes/:?]
> 	at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:962) [classes/:?]
> 	at org.jgroups.protocols.pbcast.NAKACK2.removeAndDeliver(NAKACK2.java:896) [classes/:?]
> 	at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:870) [classes/:?]
> 	at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:690) [classes/:?]
> 	at org.jgroups.stack.Protocol.up(Protocol.java:372) [classes/:?]
> 	at org.jgroups.protocols.TP.passBatchUp(TP.java:1255) [classes/:?]
> 	at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.passBatchUp(MaxOneThreadPerSender.java:284) [classes/:?]
> 	at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136) [classes/:?]
> 	at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.run(MaxOneThreadPerSender.java:273) [classes/:?]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_151]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_151]
> 	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_151]
> {noformat}



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

From issues at jboss.org  Tue Dec  5 10:16:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 5 Dec 2017 10:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2239) AUTH + ASYM_ENCRYPT causes
 problem with re-joining cluster (MERGE)
In-Reply-To: <JIRA.12723237.1512373185000@Atlassian.JIRA>
References: <JIRA.12723237.1512373185000@Atlassian.JIRA>
	<JIRA.12723237.1512373185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723237.1512373185000.81557.1512486960324@Atlassian.JIRA>


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

Bela Ban updated JGRP-2239:
---------------------------
    Fix Version/s: 4.0.10
                       (was: 4.0.9)


> AUTH + ASYM_ENCRYPT causes problem with re-joining cluster (MERGE)
> ------------------------------------------------------------------
>
>                 Key: JGRP-2239
>                 URL: https://issues.jboss.org/browse/JGRP-2239
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.6
>         Environment: Infinispan 9.1.1 + JGroups 4.0.6.Final + Vert.x 3.5.0
>            Reporter: Boris Sh
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> Hello,
> I am using the following configuration:
> {code:java}
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> 	<UDP />
> 	<PING />
> 	<MERGE3 />
> 	<FD />
> 	<VERIFY_SUSPECT />
> 	<ASYM_ENCRYPT encrypt_entire_message="true" sym_keylength="128"
> 		sym_algorithm="AES/ECB/PKCS5Padding" asym_keylength="2048"
> 		asym_algorithm="RSA" />
> 	<pbcast.NAKACK2 />
> 	<UNICAST3 />
> 	<pbcast.STABLE />
> 	<FRAG2 />
> 	<AUTH auth_class="org.jgroups.auth.X509Token" auth_value="auth"
> 		keystore_path="keystore.jks" keystore_password="pwd" cert_alias="alias"
> 		cipher_type="RSA" />
> 	<pbcast.GMS />
> </config>
> {code}
> I have 7 services, but will try to show logs for 2 ones, coordinator and some random node, and all the other nodes behave similarly.
> Initially, when these nodes join the cluster, everything is fine.
> The server is a shared machine with slow CPU and also slow HDD, so sometimes, when other applications are busy with their tasks, whole my cluster can get frozen for 3-5 minutes. During/in the end of this freeze, some service may tell me the following (in logs):
> {code:java}
> org.jgroups.protocols.FD up
> WARNING: node-26978: I was suspected by node-27291; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-27291
>  org.jgroups.protocols.Encrypt handleEncryptedMessage
> WARNING: node-26978: unrecognized cipher; discarding message from node-36734
> org.jgroups.protocols.Encrypt handleEncryptedMessage
> {code}
> so the node was kicked out from the cluster, as it became "suspect", but the node doesn't agree with that fact. Cluster coordinator has already changed sym private key, so in the further logs of this server I see "unrecognized cipher".
> In cluster coordinator logs I see the following:
> {code:java}
> INFO: ISPN100000: Node node-26978 joined the cluster
> ****
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> org.jgroups.logging.Slf4jLogImpl error
> ERROR: key requester  node-26978 is not in current view [***]; ignoring key request
> org.jgroups.logging.Slf4jLogImpl warn
> WARN: node-27291: unrecognized cipher; discarding message from node-26978
> INFO: ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[node-26978|8] (7) [node-26978, node-12721, node-17625, node-45936, node-56674, node-36734, node-27291], 2 subgroups: [node-27291|7] (6) [node-27291, node-12721, node-17625, node-45936, node-56674, node-36734], [node-27291|6] (7) [node-27291, node-26978, node-12721, node-17625, node-45936, node-56674, node-36734]
> {code}
> My understanding of what has happened:
> For example I have 3 nodes {A, B, C} in the cluster. The cluster gets frozen for some minutes, so node {C} becomes suspected, and kicked out from the cluster by coordinator. For some reason {C} ignores that fact. Later, after cluster is up again, it becomes ignoring messages from {C}, because it is using ASYM encryption and private key has been re-generated by coordinator. Also, for some reason MERGE operation doesn't work, and {C} can not join back to cluster, and now cluster has 2 subgroups, that don't communicate to each other, and I don't fully understand why this happens.
> How I temporary resolved this issue: changed ASYM_ENCRYPT to SYM_ENCRYPT, and now any node can come back to the cluster successfully after freeze, as the key doesn't change.
> Also, I didn't test, but think change_key_on_leave="false" will help, but this is not the way I want to use.
> So looks like this a problem with AUTH + ASYM_ENCRYPT protocol combination, when node in some cases can not rejoin the cluster.



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

From issues at jboss.org  Tue Dec  5 10:16:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 5 Dec 2017 10:16: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.81561.1512486960405@Atlassian.JIRA>


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

Bela Ban updated JGRP-2232:
---------------------------
    Fix Version/s: 4.0.10
                       (was: 4.0.9)


> 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:
> 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)
> ...



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

From issues at jboss.org  Tue Dec  5 11:01:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 11:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1300) Pem.parsePemX509Certificate()
 cannot parse files with non-PEM content
In-Reply-To: <JIRA.12703136.1500645599000@Atlassian.JIRA>
References: <JIRA.12703136.1500645599000@Atlassian.JIRA>
	<JIRA.12703136.1500645599000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703136.1500645599000.81788.1512489660287@Atlassian.JIRA>


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

Jan Kalina commented on ELY-1300:
---------------------------------

[~dlofthouse] This could be good isolated starting point for new intern [~mmazanek] - he say he is be interested, would be ok to assing to him?

> Pem.parsePemX509Certificate() cannot parse files with non-PEM content
> ---------------------------------------------------------------------
>
>                 Key: ELY-1300
>                 URL: https://issues.jboss.org/browse/ELY-1300
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>
> Add a test like this to `PemTest`:
> {code}
>     @Test
>     public void testParsePemX509Certificate01() throws Exception {
>         URL url = PemTest.class.getResource("/ca/certs/01.pem");
>         byte[] bytes = Files.readAllBytes(Paths.get(url.toURI()));
>         assertNotNull(Pem.parsePemX509Certificate(CodePointIterator.ofUtf8Bytes(bytes)));
>     }
> {code}
> Note that {{ca/certs/01.pem}} should start with non-PEM content
> {code}
> Certificate:
>     Data:
> ...
> {code}
> followed by the PEM content:
> {code}
> -----BEGIN CERTIFICATE-----
> {code}
> Run the test
> {code}
> mvn clean test -Dtest=PemTest#testParsePemX509Certificate01
> {code}
> Expected: Not quite sure if the parser should accept this. In any case, the following code works on Oracle/OpenJDK (while it does not on IBM JDK):
> {code}
>         CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
>         InputStream is = X509EvidenceVerificationSuiteChild.class.getResourceAsStream("/ca/certs/01.pem");
>         Assert.assertNotNull((X509Certificate) certificateFactory.generateCertificate(is));
> {code}
> Actual: 
> {code}
> testParsePemX509Certificate01(org.wildfly.security.util.PemTest)  Time elapsed: 0.116 sec  <<< ERROR!
> java.lang.IllegalArgumentException: ELY03010: Malformed PEM content at offset 1
> 	at org.wildfly.security.pem.Pem.parsePemContent(Pem.java:79)
> 	at org.wildfly.security.pem.Pem.parsePemX509Certificate(Pem.java:272)
> 	at org.wildfly.security.util.PemTest.testParsePemX509Certificate01(PemTest.java:57)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	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 message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec  5 11:09:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 5 Dec 2017 11:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1300) Pem.parsePemX509Certificate()
 cannot parse files with non-PEM content
In-Reply-To: <JIRA.12703136.1500645599000@Atlassian.JIRA>
References: <JIRA.12703136.1500645599000@Atlassian.JIRA>
	<JIRA.12703136.1500645599000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703136.1500645599000.81843.1512490140591@Atlassian.JIRA>


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

Jan Kalina reassigned ELY-1300:
-------------------------------

    Assignee: Martin Mazanek  (was: Jan Kalina)


> Pem.parsePemX509Certificate() cannot parse files with non-PEM content
> ---------------------------------------------------------------------
>
>                 Key: ELY-1300
>                 URL: https://issues.jboss.org/browse/ELY-1300
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Peter Palaga
>            Assignee: Martin Mazanek
>
> Add a test like this to `PemTest`:
> {code}
>     @Test
>     public void testParsePemX509Certificate01() throws Exception {
>         URL url = PemTest.class.getResource("/ca/certs/01.pem");
>         byte[] bytes = Files.readAllBytes(Paths.get(url.toURI()));
>         assertNotNull(Pem.parsePemX509Certificate(CodePointIterator.ofUtf8Bytes(bytes)));
>     }
> {code}
> Note that {{ca/certs/01.pem}} should start with non-PEM content
> {code}
> Certificate:
>     Data:
> ...
> {code}
> followed by the PEM content:
> {code}
> -----BEGIN CERTIFICATE-----
> {code}
> Run the test
> {code}
> mvn clean test -Dtest=PemTest#testParsePemX509Certificate01
> {code}
> Expected: Not quite sure if the parser should accept this. In any case, the following code works on Oracle/OpenJDK (while it does not on IBM JDK):
> {code}
>         CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
>         InputStream is = X509EvidenceVerificationSuiteChild.class.getResourceAsStream("/ca/certs/01.pem");
>         Assert.assertNotNull((X509Certificate) certificateFactory.generateCertificate(is));
> {code}
> Actual: 
> {code}
> testParsePemX509Certificate01(org.wildfly.security.util.PemTest)  Time elapsed: 0.116 sec  <<< ERROR!
> java.lang.IllegalArgumentException: ELY03010: Malformed PEM content at offset 1
> 	at org.wildfly.security.pem.Pem.parsePemContent(Pem.java:79)
> 	at org.wildfly.security.pem.Pem.parsePemX509Certificate(Pem.java:272)
> 	at org.wildfly.security.util.PemTest.testParsePemX509Certificate01(PemTest.java:57)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	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 message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec  5 11:33:01 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 5 Dec 2017 11:33:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8697) Address
 DeploymentUnitProcessor leaks in the codebase
In-Reply-To: <JIRA.12690586.1493841887000@Atlassian.JIRA>
References: <JIRA.12690586.1493841887000@Atlassian.JIRA>
	<JIRA.12690586.1493841887000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12690586.1493841887000.82038.1512491581836@Atlassian.JIRA>


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

RH Bugzilla Integration commented on WFLY-8697:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1500297|https://bugzilla.redhat.com/show_bug.cgi?id=1500297] from POST to MODIFIED

> Address DeploymentUnitProcessor leaks in the codebase
> -----------------------------------------------------
>
>                 Key: WFLY-8697
>                 URL: https://issues.jboss.org/browse/WFLY-8697
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.Beta1
>
>
> In order to get singleton deployments fully working, we need to address the numerous {{org.jboss.as.server.deployment.DeploymentUnitProcessor#undeploy}} implementation leaks.



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

From issues at jboss.org  Tue Dec  5 12:07:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 5 Dec 2017 12:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0
 could be instantiated twice: once as a reader and once as a writer
In-Reply-To: <JIRA.12723577.1512493570000@Atlassian.JIRA>
References: <JIRA.12723577.1512493570000@Atlassian.JIRA>
	<JIRA.12723577.1512493570005@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723577.1512493570000.82230.1512493620296@Atlassian.JIRA>

Radoslav Husar created WFLY-9597:
------------------------------------

             Summary: UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
                 Key: WFLY-9597
                 URL: https://issues.jboss.org/browse/WFLY-9597
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Radoslav Husar
            Assignee: Tomaz Cerar


The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422cf4b92c/undertow/src/main/java/org/wildfly/extension/undertow/UndertowExtension.java#L100-L113



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

From issues at jboss.org  Tue Dec  5 12:07:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 5 Dec 2017 12:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0
 could be instantiated twice: once as a reader and once as a writer
In-Reply-To: <JIRA.12723577.1512493570000@Atlassian.JIRA>
References: <JIRA.12723577.1512493570000@Atlassian.JIRA>
	<JIRA.12723577.1512493570000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723577.1512493570000.82236.1512493620459@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-9597:
---------------------------------
    Description: 
The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422cf4b92c/undertow/src/main/java/org/wildfly/extension/undertow/UndertowExtension.java#L100-L113
Most likely the same issue is in multiple places.

  was:The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422cf4b92c/undertow/src/main/java/org/wildfly/extension/undertow/UndertowExtension.java#L100-L113



> UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9597
>                 URL: https://issues.jboss.org/browse/WFLY-9597
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Radoslav Husar
>            Assignee: Tomaz Cerar
>
> The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422cf4b92c/undertow/src/main/java/org/wildfly/extension/undertow/UndertowExtension.java#L100-L113
> Most likely the same issue is in multiple places.



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

From issues at jboss.org  Tue Dec  5 12:11:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Dec 2017 12:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0
 could be instantiated twice: once as a reader and once as a writer
In-Reply-To: <JIRA.12723577.1512493570000@Atlassian.JIRA>
References: <JIRA.12723577.1512493570000@Atlassian.JIRA>
	<JIRA.12723577.1512493570000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723577.1512493570000.82279.1512493860285@Atlassian.JIRA>


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

Paul Ferraro commented on WFLY-9597:
------------------------------------

N.B. this likely affects other subsystems that make use of PersistentResourceXMLParser, and has a negative impact on WF's memory footprint.  This becomes increasingly significant as a consequence of https://issues.jboss.org/browse/WFCORE-3441

> UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9597
>                 URL: https://issues.jboss.org/browse/WFLY-9597
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Radoslav Husar
>            Assignee: Tomaz Cerar
>
> The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422cf4b92c/undertow/src/main/java/org/wildfly/extension/undertow/UndertowExtension.java#L100-L113
> Most likely the same issue is in multiple places.



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

From issues at jboss.org  Tue Dec  5 13:08:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 5 Dec 2017 13:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0
 could be instantiated twice: once as a reader and once as a writer
In-Reply-To: <JIRA.12723577.1512493570000@Atlassian.JIRA>
References: <JIRA.12723577.1512493570000@Atlassian.JIRA>
	<JIRA.12723577.1512493570000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723577.1512493570000.82377.1512497280211@Atlassian.JIRA>


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

Brian Stansberry commented on WFLY-9597:
----------------------------------------

Part of the reason I filed WFCORE-3441 is I wanted consideration of this kind thing before people started just blindly moving to a Supplier in order to make a deprecation warn go away.

There are a number of intersecting factors to balance in all this.

1) If the parsers and marshallers are basically stateless objects, the class space for the Supplier is more than the cost of an object.
2) A PersistentResourceXMLParser implementation may or may not be stateless, depending on how it is coded. Some store the PersistentResourceXMLDescription in a static field (making the class itself somewhat heavy but an instance stateless), some in an instance field, and some calculate it on the fly.
3) For the current version of a parser, it's actually important to boot time that a PersistentResourceXMLDescription be created during Extension.initializeParsers and not deferred to when parsing happens. Extension.initializeParsers is done concurrently while parsing is single threaded, and creating the PersistentResourceXMLDescription ends up being the trigger that loads most of the extensions management model classes, creates AttributeDefinitions etc.

Likely the most efficient way to do this with a PersistentResourceXMLParser is:

{code}
class FooExtension implements Extension {

  private volatile PersistentResourceXmlParser currentParserMarshaller;

  private PersistentResourceXmlParser getCurrentParserMarshaller() {
       PersistentResourceXmlParser result = currentParserMarshaller;
       if (result == null) {
           result = currentParserMarshaller = new FooParser3_0();
        }
        return result;
    }

    public void initializeParsers(ExtensionParsingContext context) {
        .... register legacy parsers using the Supplier API
        context.setSubsystemXmlMapping("foo",  FOO_3_URI, getCurrentParserMarshaller());
    }

    public void initialize(ExtensionContext context) {
        .... do the other stuff
        subsystem.registerXMLElementWriter(getCurrentParserMarshaller());
    }

}
{code}

That's kind of fussy code, but oh well.
        

> UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9597
>                 URL: https://issues.jboss.org/browse/WFLY-9597
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Radoslav Husar
>            Assignee: Tomaz Cerar
>
> The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422cf4b92c/undertow/src/main/java/org/wildfly/extension/undertow/UndertowExtension.java#L100-L113
> Most likely the same issue is in multiple places.



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

From issues at jboss.org  Tue Dec  5 13:15:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 5 Dec 2017 13:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0
 could be instantiated twice: once as a reader and once as a writer
In-Reply-To: <JIRA.12723577.1512493570000@Atlassian.JIRA>
References: <JIRA.12723577.1512493570000@Atlassian.JIRA>
	<JIRA.12723577.1512493570000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723577.1512493570000.82389.1512497700342@Atlassian.JIRA>


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

Brian Stansberry edited comment on WFLY-9597 at 12/5/17 1:14 PM:
-----------------------------------------------------------------

Part of the reason I filed WFCORE-3441 is I wanted consideration of this kind thing before people started just blindly moving to a Supplier in order to make a deprecation warn go away.

There are a number of intersecting factors to balance in all this.

1) If the parsers and marshallers are basically stateless objects, the class space for the Supplier is more than the cost of an object.
2) A PersistentResourceXMLParser implementation may or may not be stateless, depending on how it is coded. Some store the PersistentResourceXMLDescription in a static field (making the class itself somewhat heavy but an instance stateless), some in an instance field, and some calculate it on the fly.
3) For the current version of a parser, it's actually important to boot time that a PersistentResourceXMLDescription be created during Extension.initializeParsers and not deferred to when parsing happens. Extension.initializeParsers is done concurrently while parsing is single threaded, and creating the PersistentResourceXMLDescription ends up being the trigger that loads most of the extension's management model classes, creates AttributeDefinitions etc.

Likely the most efficient way to do this with a PersistentResourceXMLParser is:

{code}
class FooExtension implements Extension {

  private volatile PersistentResourceXmlParser currentParserMarshaller;

  private PersistentResourceXmlParser getCurrentParserMarshaller() {
       PersistentResourceXmlParser result = currentParserMarshaller;
       if (result == null) {
           result = currentParserMarshaller = new FooParser3_0();
        }
        return result;
    }

    public void initializeParsers(ExtensionParsingContext context) {
        .... register legacy parsers using the Supplier API
        context.setSubsystemXmlMapping("foo",  FOO_3_URI, getCurrentParserMarshaller());
    }

    public void initialize(ExtensionContext context) {
        .... do the other stuff
        subsystem.registerXMLElementWriter(getCurrentParserMarshaller());
    }

}
{code}

The PersistentResourceXmlParser subclass itself would not cache the PersistentResourceXMLDescription, it would create it when asked. The ExtensionRegistry itself triggers a single-use caching of the PersistentResourceXMLDescription if a PersistentResourceXmlParser is passed to context.setSubsystemXmlMapping. It's a single use cache, so when the document is parsed at boot it would be discarded.

All of this is black art, which sucks. But barring a rewrite of Extension etc, which isn't happening for WF 12, I think black art is what we need to do.
        


was (Author: brian.stansberry):
Part of the reason I filed WFCORE-3441 is I wanted consideration of this kind thing before people started just blindly moving to a Supplier in order to make a deprecation warn go away.

There are a number of intersecting factors to balance in all this.

1) If the parsers and marshallers are basically stateless objects, the class space for the Supplier is more than the cost of an object.
2) A PersistentResourceXMLParser implementation may or may not be stateless, depending on how it is coded. Some store the PersistentResourceXMLDescription in a static field (making the class itself somewhat heavy but an instance stateless), some in an instance field, and some calculate it on the fly.
3) For the current version of a parser, it's actually important to boot time that a PersistentResourceXMLDescription be created during Extension.initializeParsers and not deferred to when parsing happens. Extension.initializeParsers is done concurrently while parsing is single threaded, and creating the PersistentResourceXMLDescription ends up being the trigger that loads most of the extensions management model classes, creates AttributeDefinitions etc.

Likely the most efficient way to do this with a PersistentResourceXMLParser is:

{code}
class FooExtension implements Extension {

  private volatile PersistentResourceXmlParser currentParserMarshaller;

  private PersistentResourceXmlParser getCurrentParserMarshaller() {
       PersistentResourceXmlParser result = currentParserMarshaller;
       if (result == null) {
           result = currentParserMarshaller = new FooParser3_0();
        }
        return result;
    }

    public void initializeParsers(ExtensionParsingContext context) {
        .... register legacy parsers using the Supplier API
        context.setSubsystemXmlMapping("foo",  FOO_3_URI, getCurrentParserMarshaller());
    }

    public void initialize(ExtensionContext context) {
        .... do the other stuff
        subsystem.registerXMLElementWriter(getCurrentParserMarshaller());
    }

}
{code}

That's kind of fussy code, but oh well.
        

> UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9597
>                 URL: https://issues.jboss.org/browse/WFLY-9597
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Radoslav Husar
>            Assignee: Tomaz Cerar
>
> The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422cf4b92c/undertow/src/main/java/org/wildfly/extension/undertow/UndertowExtension.java#L100-L113
> Most likely the same issue is in multiple places.



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

From issues at jboss.org  Tue Dec  5 14:45:00 2017
From: issues at jboss.org (Derek Horton (JIRA))
Date: Tue, 5 Dec 2017 14:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3448) Unable to set multiple ssl
 protocols and ciphers on security-realms using system properties
In-Reply-To: <JIRA.12723606.1512503095000@Atlassian.JIRA>
References: <JIRA.12723606.1512503095000@Atlassian.JIRA>
	<JIRA.12723606.1512503095873@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723606.1512503095000.82517.1512503100108@Atlassian.JIRA>

Derek Horton created WFCORE-3448:
------------------------------------

             Summary: Unable to set multiple ssl protocols and ciphers on security-realms using system properties
                 Key: WFCORE-3448
                 URL: https://issues.jboss.org/browse/WFCORE-3448
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Derek Horton
            Assignee: Brian Stansberry


It is not possible to set the ssl protocol and ciphers on a security-realm using system property if multiple protocols and/or ciphers are needed.

Setting the "enabled-cipher-suites" and  "enabled-protocols" using a system property works if the system property value resolves to a single value ("TLSv1.2" for example).

An error is thrown if the system property has multiple values (-Dtlsversion="TLSv1.1 TLSv1.2").  Here is the error that is generated:

13:20:43,315 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: WFLYDM0096: No protocols in common, supported=([SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]), requested=([TLSv1.1 TLSv1.2])
        at org.jboss.as.domain.management.security.SSLContextService.wrapSslContext(SSLContextService.java:137)
        at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:102)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
        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 Dec  5 14:57:00 2017
From: issues at jboss.org (Derek Horton (JIRA))
Date: Tue, 5 Dec 2017 14:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3448) Unable to set multiple ssl
 protocols and ciphers on security-realms using system properties
In-Reply-To: <JIRA.12723606.1512503096000@Atlassian.JIRA>
References: <JIRA.12723606.1512503096000@Atlassian.JIRA>
	<JIRA.12723606.1512503096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723606.1512503096000.82528.1512503820404@Atlassian.JIRA>


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

Derek Horton updated WFCORE-3448:
---------------------------------
      Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2972
    Steps to Reproduce: 
- add a security-realm that has ssl enabled

            <security-realm name="CertificateRealm">
                <server-identities>
                    <ssl>

                        <engine enabled-cipher-suites="${tlscipher}" enabled-protocols="${tlsversion}"/>
                        <keystore path="/home/dehort/dev/java/jboss-eap-6.4.17/domain/configuration/server.keystore" keystore-password="123456" alias="serverkeys"/>
                    </ssl>
                </server-identities>
            </security-realm>

- start JBoss with the required system properties (must use multiple values to reproduce the issue)

  ./bin/standalone.sh -Dtlscipher="TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA" -Dtlsversion="TLSv1.1 TLSv1.2"

  was:

- add a security-realm that has ssl enabled

            <security-realm name="CertificateRealm">
                <server-identities>
                    <ssl>

                        <engine enabled-cipher-suites="${tlscipher}" enabled-protocols="${tlsversion}"/>
                        <keystore path="/home/dehort/dev/java/jboss-eap-6.4.17/domain/configuration/server.keystore" keystore-password="123456" alias="serverkeys"/>
                    </ssl>
                </server-identities>
            </security-realm>

- start JBoss with the required system properties (must use multiple values to reproduce the issue)

  ./bin/standalone.sh -Dtlscipher="TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA" -Dtlsversion="TLSv1.1 TLSv1.2"



> Unable to set multiple ssl protocols and ciphers on security-realms using system properties
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3448
>                 URL: https://issues.jboss.org/browse/WFCORE-3448
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Derek Horton
>            Assignee: Brian Stansberry
>
> It is not possible to set the ssl protocol and ciphers on a security-realm using system property if multiple protocols and/or ciphers are needed.
> Setting the "enabled-cipher-suites" and  "enabled-protocols" using a system property works if the system property value resolves to a single value ("TLSv1.2" for example).
> An error is thrown if the system property has multiple values (-Dtlsversion="TLSv1.1 TLSv1.2").  Here is the error that is generated:
> 13:20:43,315 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: WFLYDM0096: No protocols in common, supported=([SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]), requested=([TLSv1.1 TLSv1.2])
>         at org.jboss.as.domain.management.security.SSLContextService.wrapSslContext(SSLContextService.java:137)
>         at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:102)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
>         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 Dec  5 14:57:00 2017
From: issues at jboss.org (Derek Horton (JIRA))
Date: Tue, 5 Dec 2017 14:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3449) [GSS] (7.x) Unable to set
 multiple ssl protocols and ciphers on security-realms using system
 properties
In-Reply-To: <JIRA.12723607.1512503809000@Atlassian.JIRA>
References: <JIRA.12723607.1512503809000@Atlassian.JIRA>
	<JIRA.12723607.1512503809776@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723607.1512503809000.82534.1512503820570@Atlassian.JIRA>

Derek Horton created WFCORE-3449:
------------------------------------

             Summary: [GSS] (7.x) Unable to set multiple ssl protocols and ciphers on security-realms using system properties
                 Key: WFCORE-3449
                 URL: https://issues.jboss.org/browse/WFCORE-3449
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Derek Horton
            Assignee: Brian Stansberry


It is not possible to set the ssl protocol and ciphers on a security-realm using system property if multiple protocols and/or ciphers are needed.

Setting the "enabled-cipher-suites" and  "enabled-protocols" using a system property works if the system property value resolves to a single value ("TLSv1.2" for example).

An error is thrown if the system property has multiple values (-Dtlsversion="TLSv1.1 TLSv1.2").  Here is the error that is generated:

13:20:43,315 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: WFLYDM0096: No protocols in common, supported=([SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]), requested=([TLSv1.1 TLSv1.2])
        at org.jboss.as.domain.management.security.SSLContextService.wrapSslContext(SSLContextService.java:137)
        at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:102)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
        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 Dec  5 15:31:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 5 Dec 2017 15:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3448) Unable to set multiple ssl
 protocols and ciphers on security-realms using system properties
In-Reply-To: <JIRA.12723606.1512503096000@Atlassian.JIRA>
References: <JIRA.12723606.1512503096000@Atlassian.JIRA>
	<JIRA.12723606.1512503096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723606.1512503096000.82605.1512505860532@Atlassian.JIRA>


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

Brian Stansberry updated WFCORE-3448:
-------------------------------------
    Issue Type: Enhancement  (was: Bug)


> Unable to set multiple ssl protocols and ciphers on security-realms using system properties
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3448
>                 URL: https://issues.jboss.org/browse/WFCORE-3448
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Derek Horton
>            Assignee: Brian Stansberry
>
> It is not possible to set the ssl protocol and ciphers on a security-realm using system property if multiple protocols and/or ciphers are needed.
> Setting the "enabled-cipher-suites" and  "enabled-protocols" using a system property works if the system property value resolves to a single value ("TLSv1.2" for example).
> An error is thrown if the system property has multiple values (-Dtlsversion="TLSv1.1 TLSv1.2").  Here is the error that is generated:
> 13:20:43,315 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: WFLYDM0096: No protocols in common, supported=([SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]), requested=([TLSv1.1 TLSv1.2])
>         at org.jboss.as.domain.management.security.SSLContextService.wrapSslContext(SSLContextService.java:137)
>         at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:102)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
>         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 Dec  5 17:29:00 2017
From: issues at jboss.org (Darryl Miles (JIRA))
Date: Tue, 5 Dec 2017 17:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9074) NPE
 o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
In-Reply-To: <JIRA.12701502.1499787041000@Atlassian.JIRA>
References: <JIRA.12701502.1499787041000@Atlassian.JIRA>
	<JIRA.12701502.1499787041000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12701502.1499787041000.82952.1512512940544@Atlassian.JIRA>


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

Darryl Miles commented on WFLY-9074:
------------------------------------

[~tomekadamski]  Yes there are a number of "@Startup" and "@Singleton" EJBs across the entire application.

> NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
> -----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9074
>                 URL: https://issues.jboss.org/browse/WFLY-9074
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Darryl Miles
>            Assignee: Tomasz Adamski
>             Fix For: 12.0.0.Alpha1
>
>
> https://issues.jboss.org/browse/WFLY-6663  (see fix for this other bug, maybe the 1 line wait method is needed somewhere else too?)
> Much more intermittent matter (I guess the time window is smaller).
> 16:14:04,428 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 19) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	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:748)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	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)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	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)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	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.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 28 more
> Caused by: javax.naming.NameNotFoundException: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 45 more
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 50 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:57)
> 	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$DefaultViewInstanceFactory.createViewInstance(ViewService.java:305)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> 	... 51 more



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

From issues at jboss.org  Tue Dec  5 17:31:00 2017
From: issues at jboss.org (Darryl Miles (JIRA))
Date: Tue, 5 Dec 2017 17:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9074) NPE
 o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
In-Reply-To: <JIRA.12701502.1499787041000@Atlassian.JIRA>
References: <JIRA.12701502.1499787041000@Atlassian.JIRA>
	<JIRA.12701502.1499787041000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12701502.1499787041000.82957.1512513060543@Atlassian.JIRA>


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

Darryl Miles edited comment on WFLY-9074 at 12/5/17 5:30 PM:
-------------------------------------------------------------

[~tomekadamski]  Yes there are a number of "@Startup" with "@Singleton" EJBs across the entire application.

Some have non-default "@TransactionManager" and/or "@ConcurrencyManagement" all combinations exist across the application.


was (Author: dlmiles):
[~tomekadamski]  Yes there are a number of "@Startup" and "@Singleton" EJBs across the entire application.

> NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
> -----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9074
>                 URL: https://issues.jboss.org/browse/WFLY-9074
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Darryl Miles
>            Assignee: Tomasz Adamski
>             Fix For: 12.0.0.Alpha1
>
>
> https://issues.jboss.org/browse/WFLY-6663  (see fix for this other bug, maybe the 1 line wait method is needed somewhere else too?)
> Much more intermittent matter (I guess the time window is smaller).
> 16:14:04,428 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 19) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	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:748)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	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)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	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)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	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.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 28 more
> Caused by: javax.naming.NameNotFoundException: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 45 more
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 50 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:57)
> 	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$DefaultViewInstanceFactory.createViewInstance(ViewService.java:305)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> 	... 51 more



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

From issues at jboss.org  Tue Dec  5 17:32:00 2017
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Tue, 5 Dec 2017 17:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9074) NPE
 o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
In-Reply-To: <JIRA.12701502.1499787041000@Atlassian.JIRA>
References: <JIRA.12701502.1499787041000@Atlassian.JIRA>
	<JIRA.12701502.1499787041000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12701502.1499787041000.82965.1512513120343@Atlassian.JIRA>


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

Tomasz Adamski commented on WFLY-9074:
--------------------------------------

OK thanks for info. I just wanted to confirm that the reproducer that I created has the same failure scenario. Anyway, the fix have been merged already and you shouldn't encounter this problem from WildFly 12.

> NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
> -----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9074
>                 URL: https://issues.jboss.org/browse/WFLY-9074
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Darryl Miles
>            Assignee: Tomasz Adamski
>             Fix For: 12.0.0.Alpha1
>
>
> https://issues.jboss.org/browse/WFLY-6663  (see fix for this other bug, maybe the 1 line wait method is needed somewhere else too?)
> Much more intermittent matter (I guess the time window is smaller).
> 16:14:04,428 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 19) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	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:748)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	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)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	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)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	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.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 28 more
> Caused by: javax.naming.NameNotFoundException: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 45 more
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 50 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:57)
> 	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$DefaultViewInstanceFactory.createViewInstance(ViewService.java:305)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> 	... 51 more



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

From issues at jboss.org  Tue Dec  5 17:38:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 5 Dec 2017 17:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0
 could be instantiated twice: once as a reader and once as a writer
In-Reply-To: <JIRA.12723577.1512493570000@Atlassian.JIRA>
References: <JIRA.12723577.1512493570000@Atlassian.JIRA>
	<JIRA.12723577.1512493570000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723577.1512493570000.82979.1512513480292@Atlassian.JIRA>


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

Tomaz Cerar commented on WFLY-9597:
-----------------------------------

It doesn't really matter.

This is done so we can garbage collect better.

Writer is only created when it is needed, which in most common scenario is not very often, as usually you just start the server (that reads the config) and than unless you ever change config at runtime (which is rare in production) writer never gets created.

so in short. this is by design that makes readers & writers short lived for the purpose when they are needed.


> UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9597
>                 URL: https://issues.jboss.org/browse/WFLY-9597
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Radoslav Husar
>            Assignee: Tomaz Cerar
>
> The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422cf4b92c/undertow/src/main/java/org/wildfly/extension/undertow/UndertowExtension.java#L100-L113
> Most likely the same issue is in multiple places.



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

From issues at jboss.org  Tue Dec  5 18:15:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Dec 2017 18:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0
 could be instantiated twice: once as a reader and once as a writer
In-Reply-To: <JIRA.12723577.1512493570000@Atlassian.JIRA>
References: <JIRA.12723577.1512493570000@Atlassian.JIRA>
	<JIRA.12723577.1512493570000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723577.1512493570000.83003.1512515700215@Atlassian.JIRA>


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

Paul Ferraro commented on WFLY-9597:
------------------------------------

If we're concerned about metaspace costs, we should consider eliminating the need for each consumer of PersistentResourceDefinition to create subclasses of PersistentResourceXmlParser per version (since these classes are loaded regardless of whether they are instantiated).  Additionally, the PersistentResourceXmlParser subclasses for non-current versions unnecessarily implement XMLElementWriter<ModelNode>, the implementations of which are never used.
Instead, we could create 2 concrete classes, let's call them PersistentResourceXmlReader and PersistentResourceXMLWriter, each constructed with a version specific PersistentResourceXMLDescription (or Supplier<PersistentResourceXMLDescription>).  This way the PersistentResourceXMLDescription is still shared across writer and current reader, and we don't need all those extra subclasses per version per subsystem.

> UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9597
>                 URL: https://issues.jboss.org/browse/WFLY-9597
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Radoslav Husar
>            Assignee: Tomaz Cerar
>
> The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422cf4b92c/undertow/src/main/java/org/wildfly/extension/undertow/UndertowExtension.java#L100-L113
> Most likely the same issue is in multiple places.



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

From issues at jboss.org  Tue Dec  5 20:03:00 2017
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Tue, 5 Dec 2017 20:03: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.83133.1512522180365@Atlassian.JIRA>


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

Eduardo Martins updated WFLY-9529:
----------------------------------
    Attachment: injected-jms2.zip


> 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  Wed Dec  6 01:36:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 6 Dec 2017 01:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2132) [DMN Editor] Boxed
 Expressions: FunctionDefinition editor
In-Reply-To: <JIRA.12720928.1510654087000@Atlassian.JIRA>
References: <JIRA.12720928.1510654087000@Atlassian.JIRA>
	<JIRA.12720928.1510654087000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720928.1510654087000.83229.1512542160329@Atlassian.JIRA>


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

Jozef Marko updated DROOLS-2132:
--------------------------------
    QE Status: ON_QA  (was: NEW)


> [DMN Editor] Boxed Expressions: FunctionDefinition editor
> ---------------------------------------------------------
>
>                 Key: DROOLS-2132
>                 URL: https://issues.jboss.org/browse/DROOLS-2132
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




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

From issues at jboss.org  Wed Dec  6 01:36:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 6 Dec 2017 01:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9594) url rewriting doesnt work in
	wildfly 8.2.1
In-Reply-To: <JIRA.12723458.1512470701000@Atlassian.JIRA>
References: <JIRA.12723458.1512470701000@Atlassian.JIRA>
	<JIRA.12723458.1512470701000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723458.1512470701000.83233.1512542160417@Atlassian.JIRA>


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

Stuart Douglas commented on WFLY-9594:
--------------------------------------

Please ask for help on the forums, JIRA is for bug reports.

That said you can do this in standalone.xml using an expression-filter in the filters section. 

You probably want something like:

path-prefix(/a/) -> rewrite(/c/${remaining})

If you want to use regex:

regex('^/a/(.*)') -> rewrite('/c/${1}')



> url rewriting doesnt work in wildfly 8.2.1
> ------------------------------------------
>
>                 Key: WFLY-9594
>                 URL: https://issues.jboss.org/browse/WFLY-9594
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.1.Final
>            Reporter: SATISH POKALWAR
>            Assignee: Stuart Douglas
>
> I have an application running on wildfly 8.2.1 which is upgraded from jboss 6.4. for URL rewriting in jboss 6.4 , we have virtual server section in standlone-full.xml however to do the same on wildfly 8.2.1 its been suggested to write the rule in undertow-handlers.conf and put the same in WEB-INF directory ,however that is not working.Basically i want to rewrite http://ip_address/a and http://ip_address/b to http://ip_address/c , to do the same i have written below rule in undertow-handlers.conf it is not working, regex['^/a/$'] -> rewrite['/c/$1']. Can anyone tell if am doing anything wrong , similiar rule used to work in JBOSS 6.4 



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

From issues at jboss.org  Wed Dec  6 01:36:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 6 Dec 2017 01:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9594) url rewriting doesnt work in
	wildfly 8.2.1
In-Reply-To: <JIRA.12723458.1512470701000@Atlassian.JIRA>
References: <JIRA.12723458.1512470701000@Atlassian.JIRA>
	<JIRA.12723458.1512470701000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723458.1512470701000.83237.1512542160544@Atlassian.JIRA>


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

Stuart Douglas edited comment on WFLY-9594 at 12/6/17 1:35 AM:
---------------------------------------------------------------

Please ask for help on the forums, JIRA is for bug reports.

That said you can do this in standalone.xml using an expression-filter in the filters section. 

You probably want something like:

{code}
path-prefix(/a/) -> rewrite(/c/${remaining})
{code}

If you want to use regex:

{code}
regex('^/a/(.*)') -> rewrite('/c/${1}')
{code}




was (Author: swd847):
Please ask for help on the forums, JIRA is for bug reports.

That said you can do this in standalone.xml using an expression-filter in the filters section. 

You probably want something like:

path-prefix(/a/) -> rewrite(/c/${remaining})

If you want to use regex:

regex('^/a/(.*)') -> rewrite('/c/${1}')



> url rewriting doesnt work in wildfly 8.2.1
> ------------------------------------------
>
>                 Key: WFLY-9594
>                 URL: https://issues.jboss.org/browse/WFLY-9594
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.1.Final
>            Reporter: SATISH POKALWAR
>            Assignee: Stuart Douglas
>
> I have an application running on wildfly 8.2.1 which is upgraded from jboss 6.4. for URL rewriting in jboss 6.4 , we have virtual server section in standlone-full.xml however to do the same on wildfly 8.2.1 its been suggested to write the rule in undertow-handlers.conf and put the same in WEB-INF directory ,however that is not working.Basically i want to rewrite http://ip_address/a and http://ip_address/b to http://ip_address/c , to do the same i have written below rule in undertow-handlers.conf it is not working, regex['^/a/$'] -> rewrite['/c/$1']. Can anyone tell if am doing anything wrong , similiar rule used to work in JBOSS 6.4 



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

From issues at jboss.org  Wed Dec  6 01:37:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 6 Dec 2017 01:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9594) url rewriting doesnt work in
	wildfly 8.2.1
In-Reply-To: <JIRA.12723458.1512470701000@Atlassian.JIRA>
References: <JIRA.12723458.1512470701000@Atlassian.JIRA>
	<JIRA.12723458.1512470701000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723458.1512470701000.83241.1512542220332@Atlassian.JIRA>


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

Stuart Douglas resolved WFLY-9594.
----------------------------------
    Resolution: Rejected


> url rewriting doesnt work in wildfly 8.2.1
> ------------------------------------------
>
>                 Key: WFLY-9594
>                 URL: https://issues.jboss.org/browse/WFLY-9594
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.1.Final
>            Reporter: SATISH POKALWAR
>            Assignee: Stuart Douglas
>
> I have an application running on wildfly 8.2.1 which is upgraded from jboss 6.4. for URL rewriting in jboss 6.4 , we have virtual server section in standlone-full.xml however to do the same on wildfly 8.2.1 its been suggested to write the rule in undertow-handlers.conf and put the same in WEB-INF directory ,however that is not working.Basically i want to rewrite http://ip_address/a and http://ip_address/b to http://ip_address/c , to do the same i have written below rule in undertow-handlers.conf it is not working, regex['^/a/$'] -> rewrite['/c/$1']. Can anyone tell if am doing anything wrong , similiar rule used to work in JBOSS 6.4 



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

From issues at jboss.org  Wed Dec  6 01:41:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 6 Dec 2017 01:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1226) undeploying disabled
 deployment stops service for same runtime-name in DeploymentUndeployHandler
In-Reply-To: <JIRA.12596678.1450168528000@Atlassian.JIRA>
References: <JIRA.12596678.1450168528000@Atlassian.JIRA>
	<JIRA.12596678.1450168528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12596678.1450168528000.83274.1512542460223@Atlassian.JIRA>


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

RH Bugzilla Integration commented on WFCORE-1226:
-------------------------------------------------

Abhijit humbe <abhumbe at redhat.com> changed the Status of [bug 1280262|https://bugzilla.redhat.com/show_bug.cgi?id=1280262] from CLOSED to NEW

> undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler 
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1226
>                 URL: https://issues.jboss.org/browse/WFCORE-1226
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.4.Final
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>             Fix For: 2.0.6.Final
>
>         Attachments: WFCORE-1226-wildflytest.patch, WFCORE-1226.patch
>
>
> {noformat}
> 1. Start EAP 6.4.4 in domain mode and deploy application using following CLI command:
> ~~
> [domain at localhost:9999 /] deploy /Applications/WebApp-1.war --server-groups=main-server-group --name=WebApp-1.war --runtime-name=WebApp-1.war
> ~~~
> 2. Deploy next version of application in "disabled" state with same "runtime-name"  
> ~~~
> [domain at localhost:9999 /] deploy /Applications/WebApp-2.war --disabled --name=WebApp-2.war --runtime-name=WebApp-1.war 
> ~~~
> 3. Now use replace-deployment command to access latest version of application:
> ~~~
> [domain at localhost:9999 /] /server-group=main-server-group:replace-deployment(name=WebApp-2.war,to-replace=WebApp-1.war)
> ~~~
> its working fine,laest version of application is accessable.
> 4. Now try to undeploy old version of application
> ~~~
> /server-group=main-server-group/deployment=WebApp-1.war:undeploy()
> ~~~
> After undploying older version, we are not able to access(404) latest version of application(WebApp-2.war) as well.To access it we have to redeploy it. 
> Same steps are working fine in Standalone mode.
> {noformat}



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

From issues at jboss.org  Wed Dec  6 02:24:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 6 Dec 2017 02:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2163) [DMN Editor] Context table
 doesn't show entry type label if table is scrolled
In-Reply-To: <JIRA.12723671.1512545036000@Atlassian.JIRA>
References: <JIRA.12723671.1512545036000@Atlassian.JIRA>
	<JIRA.12723671.1512545036410@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723671.1512545036000.83311.1512545040313@Atlassian.JIRA>

Jozef Marko created DROOLS-2163:
-----------------------------------

             Summary: [DMN Editor] Context table doesn't show entry type label if table is scrolled
                 Key: DROOLS-2163
                 URL: https://issues.jboss.org/browse/DROOLS-2163
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.5.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis


Context table offers 5 types of entries while each entry has label of its own type (Literal Expression, Function Relation etc.) However this label is not shown if the user scroll the table.



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

From issues at jboss.org  Wed Dec  6 02:34:00 2017
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Wed, 6 Dec 2017 02:34:00 -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.1512545604014@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723673.1512545604000.83333.1512545640074@Atlassian.JIRA>

Miroslav Novak created WFCORE-3450:
--------------------------------------

             Summary: 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


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>.



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

From issues at jboss.org  Wed Dec  6 03:01:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Wed, 6 Dec 2017 03:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2122) Error when drl file is
 opened with in project with runtime classes
In-Reply-To: <JIRA.12720188.1510218403000@Atlassian.JIRA>
References: <JIRA.12720188.1510218403000@Atlassian.JIRA>
	<JIRA.12720188.1510218403000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720188.1510218403000.83399.1512547260376@Atlassian.JIRA>


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

Matteo Mortari commented on DROOLS-2122:
----------------------------------------

Also requires 2 commits, on droolsjbpm-knowledge and a new one on droolsjbpm-tools:
https://github.com/kiegroup/droolsjbpm-knowledge/commit/aedd33f85b4fa73bd044fce8c7b58f167423b3bf
https://github.com/kiegroup/droolsjbpm-tools/commit/b8dc98591075b7f050d96666aa71cdb4f8031388


> Error when drl file is opened with in project with runtime classes 
> -------------------------------------------------------------------
>
>                 Key: DROOLS-2122
>                 URL: https://issues.jboss.org/browse/DROOLS-2122
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>    Affects Versions: 7.3.0.Final
>         Environment: DevstudioIS 11.1.0.Beta1
> Brms 6.4.6.GA
>            Reporter: Tomas David
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 7.5.0.Final
>
>         Attachments: Screenshot from 2017-11-09 09-55-05.png, devstudiolog.log
>
>
> If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> This blocks also other functions like add a breakpoint or show content assist menu.



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

From issues at jboss.org  Wed Dec  6 03:04:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 6 Dec 2017 03:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2122) Error when drl file is
 opened with in project with runtime classes
In-Reply-To: <JIRA.12720188.1510218403000@Atlassian.JIRA>
References: <JIRA.12720188.1510218403000@Atlassian.JIRA>
	<JIRA.12720188.1510218403000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720188.1510218403000.83416.1512547440637@Atlassian.JIRA>


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

Mario Fusco commented on DROOLS-2122:
-------------------------------------

Fixed by https://github.com/kiegroup/droolsjbpm-knowledge/commit/aedd33f85b4fa73bd044fce8c7b58f167423b3bf and https://github.com/kiegroup/droolsjbpm-tools/commit/b8dc98591075b7f050d96666aa71cdb4f8031388

> Error when drl file is opened with in project with runtime classes 
> -------------------------------------------------------------------
>
>                 Key: DROOLS-2122
>                 URL: https://issues.jboss.org/browse/DROOLS-2122
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>    Affects Versions: 7.3.0.Final
>         Environment: DevstudioIS 11.1.0.Beta1
> Brms 6.4.6.GA
>            Reporter: Tomas David
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 7.5.0.Final
>
>         Attachments: Screenshot from 2017-11-09 09-55-05.png, devstudiolog.log
>
>
> If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> This blocks also other functions like add a breakpoint or show content assist menu.



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

From issues at jboss.org  Wed Dec  6 03:31:00 2017
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Wed, 6 Dec 2017 03:31:00 -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.83511.1512549060769@Atlassian.JIRA>


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

Ingo Weiss commented on WFCORE-3450:
------------------------------------

As mentioned, I think colours + '*' would be best suited. If the terminal doesn't support colours, then the '*' should suffice. Maybe we can add a note mentioning that '*' attributes are required ones?

> 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
>
> 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>.



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

From issues at jboss.org  Wed Dec  6 03:35:00 2017
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Wed, 6 Dec 2017 03:35:00 -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.83524.1512549300242@Atlassian.JIRA>


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

Rostislav Svoboda updated WFCORE-3450:
--------------------------------------
    Description: 
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 

  was:
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>.



> 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
>
> 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  Wed Dec  6 03:37:00 2017
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Wed, 6 Dec 2017 03:37:00 -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.83541.1512549420431@Atlassian.JIRA>


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

Rostislav Svoboda updated WFCORE-3450:
--------------------------------------
    Forum Reference: https://developer.jboss.org/wiki/CLI-BetterCompletionForArguments?et=watches.email.document_comment#comment-16622


> 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
>
> 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  Wed Dec  6 03:42:00 2017
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Wed, 6 Dec 2017 03:42:00 -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.83555.1512549720184@Atlassian.JIRA>


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

Rostislav Svoboda commented on WFCORE-3450:
-------------------------------------------

For color case we would need it configurable (+1 to make colors enabled) and cover following scenarios:
 * terminal supports color + CLI color on
 * terminal supports color + CLI color off
 * terminal does not support color + CLI color on
 * terminal does not support color + CLI color off

Windows seems to be the fun platform - cmd + powershell.
Some people can be using stuff like http://cmder.net/

> 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
>
> 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  Wed Dec  6 03:54:00 2017
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Wed, 6 Dec 2017 03:54:00 -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.83607.1512550440421@Atlassian.JIRA>


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

Ingo Weiss commented on WFCORE-3450:
------------------------------------

I agree with this matrix. [~jfdenise], what do you think?

> 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
>
> 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  Wed Dec  6 03:56:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 6 Dec 2017 03:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2164) [DMN Editor] New Expression
 Columns doesn't respect width of parent column
In-Reply-To: <JIRA.12723701.1512550541000@Atlassian.JIRA>
References: <JIRA.12723701.1512550541000@Atlassian.JIRA>
	<JIRA.12723701.1512550541422@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723701.1512550541000.83617.1512550560285@Atlassian.JIRA>

Jozef Marko created DROOLS-2164:
-----------------------------------

             Summary: [DMN Editor] New Expression Columns doesn't respect width of parent column
                 Key: DROOLS-2164
                 URL: https://issues.jboss.org/browse/DROOLS-2164
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.5.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis


New Expression Column doesn't respect the width of the parent column in the context table. It can be seen if the context table contains multiple entries.



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

From issues at jboss.org  Wed Dec  6 04:05:00 2017
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Wed, 6 Dec 2017 04:05:00 -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.83644.1512551100582@Atlassian.JIRA>


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

Miroslav Novak commented on WFCORE-3450:
----------------------------------------

Another possibly less painful option might be to use *bold* text for attributes but it depends whether Aesh can do it. wdyt?

> 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
>
> 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  Wed Dec  6 04:34:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 6 Dec 2017 04:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2130) [DMN Editor] Boxed
 Expressions: Relations Expression editor
In-Reply-To: <JIRA.12720911.1510651918000@Atlassian.JIRA>
References: <JIRA.12720911.1510651918000@Atlassian.JIRA>
	<JIRA.12720911.1510651918000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720911.1510651918000.83768.1512552840114@Atlassian.JIRA>


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

Jozef Marko updated DROOLS-2130:
--------------------------------
    QE Status: VERIFIED  (was: ON_QA)


> [DMN Editor] Boxed Expressions: Relations Expression editor
> -----------------------------------------------------------
>
>                 Key: DROOLS-2130
>                 URL: https://issues.jboss.org/browse/DROOLS-2130
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




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

From issues at jboss.org  Wed Dec  6 04:36:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 6 Dec 2017 04:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1949) [DMN Editor]: Context
 Editor: Row heights should be based on content
In-Reply-To: <JIRA.12708325.1503413007000@Atlassian.JIRA>
References: <JIRA.12708325.1503413007000@Atlassian.JIRA>
	<JIRA.12708325.1503413007000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12708325.1503413007000.83771.1512552960095@Atlassian.JIRA>


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

Jozef Marko commented on DROOLS-1949:
-------------------------------------

[~manstis] Hi, please is this still in progress?

> [DMN Editor]: Context Editor: Row heights should be based on content
> --------------------------------------------------------------------
>
>                 Key: DROOLS-1949
>                 URL: https://issues.jboss.org/browse/DROOLS-1949
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




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

From issues at jboss.org  Wed Dec  6 04:37:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 6 Dec 2017 04:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1949) [DMN Editor]: Context
 Editor: Row heights should be based on content
In-Reply-To: <JIRA.12708325.1503413007000@Atlassian.JIRA>
References: <JIRA.12708325.1503413007000@Atlassian.JIRA>
	<JIRA.12708325.1503413007000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12708325.1503413007000.83781.1512553020481@Atlassian.JIRA>


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

Michael Anstis resolved DROOLS-1949.
------------------------------------
    Resolution: Done


> [DMN Editor]: Context Editor: Row heights should be based on content
> --------------------------------------------------------------------
>
>                 Key: DROOLS-1949
>                 URL: https://issues.jboss.org/browse/DROOLS-1949
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




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

From issues at jboss.org  Wed Dec  6 04:38:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 6 Dec 2017 04:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1949) [DMN Editor]: Context
 Editor: Row heights should be based on content
In-Reply-To: <JIRA.12708325.1503413007000@Atlassian.JIRA>
References: <JIRA.12708325.1503413007000@Atlassian.JIRA>
	<JIRA.12708325.1503413007000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12708325.1503413007000.83783.1512553080321@Atlassian.JIRA>


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

Michael Anstis commented on DROOLS-1949:
----------------------------------------

[~jomarko] Thanks; good catch... I'm not saying there may not be issues but the initial implementation this represented is complete.

(I hope the double-negative above makes sense!!)

> [DMN Editor]: Context Editor: Row heights should be based on content
> --------------------------------------------------------------------
>
>                 Key: DROOLS-1949
>                 URL: https://issues.jboss.org/browse/DROOLS-1949
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




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

From issues at jboss.org  Wed Dec  6 04:41:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 6 Dec 2017 04:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1949) [DMN Editor]: Context
 Editor: Row heights should be based on content
In-Reply-To: <JIRA.12708325.1503413007000@Atlassian.JIRA>
References: <JIRA.12708325.1503413007000@Atlassian.JIRA>
	<JIRA.12708325.1503413007000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12708325.1503413007000.83793.1512553260362@Atlassian.JIRA>


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

Jozef Marko commented on DROOLS-1949:
-------------------------------------

[~manstis] double negative is quite usual in Slovak language, so no problem :)

> [DMN Editor]: Context Editor: Row heights should be based on content
> --------------------------------------------------------------------
>
>                 Key: DROOLS-1949
>                 URL: https://issues.jboss.org/browse/DROOLS-1949
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




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

From issues at jboss.org  Wed Dec  6 04:42:01 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 6 Dec 2017 04:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1949) [DMN Editor]: Context
 Editor: Row heights should be based on content
In-Reply-To: <JIRA.12708325.1503413007000@Atlassian.JIRA>
References: <JIRA.12708325.1503413007000@Atlassian.JIRA>
	<JIRA.12708325.1503413007000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12708325.1503413007000.83809.1512553321087@Atlassian.JIRA>


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

Jozef Marko updated DROOLS-1949:
--------------------------------
    QE Status: VERIFIED  (was: ON_QA)


> [DMN Editor]: Context Editor: Row heights should be based on content
> --------------------------------------------------------------------
>
>                 Key: DROOLS-1949
>                 URL: https://issues.jboss.org/browse/DROOLS-1949
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




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

From issues at jboss.org  Wed Dec  6 04:45:00 2017
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Wed, 6 Dec 2017 04:45:00 -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.83826.1512553500279@Atlassian.JIRA>


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

Ingo Weiss commented on WFCORE-3450:
------------------------------------

IIRC, bold requires some sort of terminal support as well. I need to do some research on that.

> 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
>
> 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  Wed Dec  6 04:51:01 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 6 Dec 2017 04:51:01 -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.1512553817000@Atlassian.JIRA>
References: <JIRA.12723714.1512553817000@Atlassian.JIRA>
	<JIRA.12723714.1512553817956@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723714.1512553817000.83847.1512553861195@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-2165:
----------------------------------------

             Summary: 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  Wed Dec  6 05:42:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 6 Dec 2017 05:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9598) Clustering Testsuite 2.0: no
 ant, CLI, 3-node DIST testing
In-Reply-To: <JIRA.12723725.1512556909000@Atlassian.JIRA>
References: <JIRA.12723725.1512556909000@Atlassian.JIRA>
	<JIRA.12723725.1512556909356@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723725.1512556909000.84063.1512556920389@Atlassian.JIRA>

Radoslav Husar created WFLY-9598:
------------------------------------

             Summary: Clustering Testsuite 2.0: no ant, CLI, 3-node DIST testing
                 Key: WFLY-9598
                 URL: https://issues.jboss.org/browse/WFLY-9598
             Project: WildFly
          Issue Type: Task
          Components: Clustering, Test Suite
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
            Priority: Critical






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

From issues at jboss.org  Wed Dec  6 05:43:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 6 Dec 2017 05:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9598) Clustering Testsuite 2.0: no
 ant, CLI, 3-node DIST testing
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.84069.1512556980556@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-9598:
---------------------------------
    Affects Version/s: 11.0.0.Final


> Clustering Testsuite 2.0: no ant, CLI, 3-node DIST testing
> ----------------------------------------------------------
>
>                 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
>
>




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

From issues at jboss.org  Wed Dec  6 05:43:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 6 Dec 2017 05:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9598) Clustering Testsuite 2.0: no
 ant, CLI, 3-node DIST testing
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.84072.1512556980661@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-9598:
---------------------------------
    Fix Version/s: 12.0.0.Alpha1


> Clustering Testsuite 2.0: no ant, CLI, 3-node DIST testing
> ----------------------------------------------------------
>
>                 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
>
>




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

From issues at jboss.org  Wed Dec  6 05:51:01 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 6 Dec 2017 05:51:01 -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.84154.1512557461075@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-9572:
---------------------------------
    Description:     (was: For starters, move the testsuite away from using XSLT and just rely on the CLI scripts. )


> 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
>




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

From issues at jboss.org  Wed Dec  6 05:52:01 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 6 Dec 2017 05:52:01 -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.84177.1512557521995@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-9572:
---------------------------------
    Description: Tracking issue for speeding up clustering 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
>
> Tracking issue for speeding up clustering testsuite.



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

From issues at jboss.org  Wed Dec  6 05:52:02 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 6 Dec 2017 05:52:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9598) Clustering Testsuite 2.0: no
 ant, CLI, 3-node DIST testing
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.84180.1512557522086@Atlassian.JIRA>


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

Radoslav Husar updated WFLY-9598:
---------------------------------
    Description: For starters, move the testsuite away from using XSLT and just rely on the CLI scripts. 


> Clustering Testsuite 2.0: no ant, CLI, 3-node DIST testing
> ----------------------------------------------------------
>
>                 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
>
>
> For starters, move the testsuite away from using XSLT and just rely on the CLI scripts. 



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

From issues at jboss.org  Wed Dec  6 06:06:00 2017
From: issues at jboss.org (Tomas Kraus (JIRA))
Date: Wed, 6 Dec 2017 06:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink
 Onscucess observer gets stale entity
In-Reply-To: <JIRA.12697927.1497863083000@Atlassian.JIRA>
References: <JIRA.12697927.1497863083000@Atlassian.JIRA>
	<JIRA.12697927.1497863083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12697927.1497863083000.84289.1512558360426@Atlassian.JIRA>


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

Tomas Kraus commented on WFLY-8954:
-----------------------------------

I made changes to implement JTA 1.1 TransactionSynchronizationRegistry in EclipseLink master branch, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=526419 for details. It would be good if you can test next http://www.eclipse.org/eclipselink/downloads/nightly.php (7th dec 2017 and later) and give us feedback. Also, if we'll make backport into 2.7. and 2.6 branches, you can base your changes on extending org.eclipse.persistence.transaction.JTA11TransactionController class instead of current JTATransactionController.


> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
>                 Key: WFLY-8954
>                 URL: https://issues.jboss.org/browse/WFLY-8954
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 10.0.0.Final
>            Reporter: Nuno Godinho de Matos
>            Assignee: Scott Marlow
>             Fix For: 12.0.0.Alpha1
>
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.



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

From issues at jboss.org  Wed Dec  6 07:21:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Wed, 6 Dec 2017 07:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-212) Automation Testcase
In-Reply-To: <JIRA.12723743.1512562832000@Atlassian.JIRA>
References: <JIRA.12723743.1512562832000@Atlassian.JIRA>
	<JIRA.12723743.1512562832784@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723743.1512562832000.84941.1512562860108@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-212:
-----------------------------------------

             Summary: Automation Testcase
                 Key: HAWKULARQE-212
                 URL: https://issues.jboss.org/browse/HAWKULARQE-212
             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  Wed Dec  6 07:31:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 6 Dec 2017 07:31: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.84973.1512563460582@Atlassian.JIRA>


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

RH Bugzilla Integration commented on WFLY-9509:
-----------------------------------------------

Aurel Pintea <apintea at redhat.com> changed the Status of [bug 1508105|https://bugzilla.redhat.com/show_bug.cgi?id=1508105] from MODIFIED to ON_QA

> 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  Wed Dec  6 07:36:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 6 Dec 2017 07:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9593) Add clustering externalizers
 for InetAddress and InetSocketAddress
In-Reply-To: <JIRA.12723366.1512407521000@Atlassian.JIRA>
References: <JIRA.12723366.1512407521000@Atlassian.JIRA>
	<JIRA.12723366.1512407521000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723366.1512407521000.85018.1512563760804@Atlassian.JIRA>


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

Paul Ferraro updated WFLY-9593:
-------------------------------
    Issue Type: Enhancement  (was: Feature Request)


> Add clustering externalizers for InetAddress and InetSocketAddress
> ------------------------------------------------------------------
>
>                 Key: WFLY-9593
>                 URL: https://issues.jboss.org/browse/WFLY-9593
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> InetAddress can be marshalled as a fixed sized array depending on whether the address is IPv4 or IPv6, which can be determined by the implementation class.
> InetSocketAddress can marshal its address using the InetAddress externalizer, and its port as an unsigned short.



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

From issues at jboss.org  Wed Dec  6 08:42:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 6 Dec 2017 08:42: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.85419.1512567720820@Atlassian.JIRA>


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

Jan Kalina edited comment on ELY-283 at 12/6/17 8:41 AM:
---------------------------------------------------------

Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*
* currently Elytron initialize LoginContext/Krb5LoginModule even if native provider should be used - should be made optional for future, but for now there is need to provide keystore with given credential to continue (obtained credential should be ignored by GSSManager if correctly set)
* Currently gssproxy supports krb5 only to have filled in mechs in gssproxy.conf - we are unable to put SPNEGO here - cannot be used for SPNEGO HTTP auth
* To start: {code}GSSPROXY_BEHAVIOR=REMOTE_FIRST GSS_USE_PROXY=1 JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.jgss.lib=/usr/lib64/libgssapi_krb5.so.2.2 -Dsun.security.jgss.native=true -Dsun.security.nativegss.debug=true -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true" bin/standalone.sh{code}


was (Author: honza889):
Few notes:
* property *sun.security.jgss.native* needs to be set using JAVA_OPTS="-D ..." before standalone.sh (setting in standalone.xml is applied to late and is ignored by JVM)
* to debug SunNativeProvider add property: *sun.security.nativegss.debug=true*
* currently Elytron initialize LoginContext/Krb5LoginModule even if native provider should be used - should be made optional for future, but for now there is need to provide keystore with given credential to continue (obtained credential should be ignored by GSSManager if correctly set)
* To start: {code}GSSPROXY_BEHAVIOR=REMOTE_FIRST GSS_USE_PROXY=1 JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.jgss.lib=/usr/lib64/libgssapi_krb5.so.2.2 -Dsun.security.jgss.native=true -Dsun.security.nativegss.debug=true -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true" bin/standalone.sh{code}

> 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
>
>
> 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 Dec  6 08:48:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 6 Dec 2017 08:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7234) Ability to identify primary
 singleton provider node
In-Reply-To: <JIRA.12652430.1475071424000@Atlassian.JIRA>
References: <JIRA.12652430.1475071424000@Atlassian.JIRA>
	<JIRA.12652430.1475071424000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652430.1475071424000.85469.1512568080228@Atlassian.JIRA>


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

Paul Ferraro updated WFLY-7234:
-------------------------------
    Issue Type: Enhancement  (was: Feature Request)


> Ability to identify primary singleton provider node
> ---------------------------------------------------
>
>                 Key: WFLY-7234
>                 URL: https://issues.jboss.org/browse/WFLY-7234
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The current Singleton interface only allow a user to tell whether or not the current node is the singleton provider.  Most backup services will proxy the service of the primary node, and thus will need to be able to identify which node is the current primary provider.



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

From issues at jboss.org  Wed Dec  6 09:17:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 6 Dec 2017 09:17: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.85703.1512569820474@Atlassian.JIRA>


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

Jozef Marko commented on DROOLS-2160:
-------------------------------------

Button size increased in PR https://github.com/kiegroup/drools-wb/pull/723

> 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: Toni Rikkola
>         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 Dec  6 09:32:00 2017
From: issues at jboss.org (Jan Hrcek (JIRA))
Date: Wed, 6 Dec 2017 09:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2166) NPE in
 KieModuleMetaDataImpl in projects with invalid pom.xml
In-Reply-To: <JIRA.12723779.1512570655000@Atlassian.JIRA>
References: <JIRA.12723779.1512570655000@Atlassian.JIRA>
	<JIRA.12723779.1512570655000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723779.1512570655000.85826.1512570720717@Atlassian.JIRA>


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

Jan Hrcek moved AF-924 to DROOLS-2166:
--------------------------------------

     Project: Drools  (was: AppFormer)
         Key: DROOLS-2166  (was: AF-924)
    Workflow: GIT Pull Request workflow   (was: classic default workflow)


> NPE in KieModuleMetaDataImpl in projects with invalid pom.xml
> -------------------------------------------------------------
>
>                 Key: DROOLS-2166
>                 URL: https://issues.jboss.org/browse/DROOLS-2166
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Jan Hrcek
>            Assignee: Eder Ignatowicz
>
> When indexing assets in projects which have some problems with pom.xml (e.g. the parent of that pom can't be resolved), there's the following exception in server.log
> {code:java}
> 14:34:46,627 ERROR [stderr] (Thread-144) java.lang.NullPointerException
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaDataImpl.init(KieModuleMetaDataImpl.java:167)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaDataImpl.<init>(KieModuleMetaDataImpl.java:86)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaData$Factory.newKieModuleMetaData(KieModuleMetaData.java:60)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.backend.builder.core.Builder.getKieModuleMetaDataIgnoringErrors(Builder.java:593)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.backend.builder.service.BuildInfoImpl.getKieModuleMetaDataIgnoringErrors(BuildInfoImpl.java:46)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.ProjectDataModelOracleBuilderProvider.newBuilder(ProjectDataModelOracleBuilderProvider.java:62)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache.makeProjectOracle(LRUProjectDataModelOracleCache.java:80)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache.assertProjectDataModelOracle(LRUProjectDataModelOracleCache.java:72)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache$Proxy$_$$_WeldClientProxy.assertProjectDataModelOracle(Unknown Source)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.DataModelServiceImpl.getProjectDataModel(DataModelServiceImpl.java:91)
> {code}
> The root cause is that kieModule.getPomModel() [here|https://github.com/kiegroup/drools/blob/master/kie-ci/src/main/java/org/kie/scanner/KieModuleMetaDataImpl.java#L167] returns null, because pom model is [not created in this case|https://github.com/kiegroup/drools/blob/master/drools-compiler/src/main/java/org/drools/compiler/kie/builder/impl/AbstractKieModule.java#L374-L388] because it can't be parsed or can't be validated.
> In this case we should at least avoid many NPEs being shown in server.log by doing null check and doing nothing if getPomModel() returns null



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

From issues at jboss.org  Wed Dec  6 09:32:00 2017
From: issues at jboss.org (Jan Hrcek (JIRA))
Date: Wed, 6 Dec 2017 09:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2166) NPE in
 KieModuleMetaDataImpl in projects with invalid pom.xml
In-Reply-To: <JIRA.12723779.1512570655000@Atlassian.JIRA>
References: <JIRA.12723779.1512570655000@Atlassian.JIRA>
	<JIRA.12723779.1512570655000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723779.1512570655000.85832.1512570720831@Atlassian.JIRA>


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

Jan Hrcek reassigned DROOLS-2166:
---------------------------------

    Assignee: Mario Fusco  (was: Eder Ignatowicz)


> NPE in KieModuleMetaDataImpl in projects with invalid pom.xml
> -------------------------------------------------------------
>
>                 Key: DROOLS-2166
>                 URL: https://issues.jboss.org/browse/DROOLS-2166
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Jan Hrcek
>            Assignee: Mario Fusco
>
> When indexing assets in projects which have some problems with pom.xml (e.g. the parent of that pom can't be resolved), there's the following exception in server.log
> {code:java}
> 14:34:46,627 ERROR [stderr] (Thread-144) java.lang.NullPointerException
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaDataImpl.init(KieModuleMetaDataImpl.java:167)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaDataImpl.<init>(KieModuleMetaDataImpl.java:86)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaData$Factory.newKieModuleMetaData(KieModuleMetaData.java:60)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.backend.builder.core.Builder.getKieModuleMetaDataIgnoringErrors(Builder.java:593)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.backend.builder.service.BuildInfoImpl.getKieModuleMetaDataIgnoringErrors(BuildInfoImpl.java:46)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.ProjectDataModelOracleBuilderProvider.newBuilder(ProjectDataModelOracleBuilderProvider.java:62)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache.makeProjectOracle(LRUProjectDataModelOracleCache.java:80)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache.assertProjectDataModelOracle(LRUProjectDataModelOracleCache.java:72)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache$Proxy$_$$_WeldClientProxy.assertProjectDataModelOracle(Unknown Source)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.DataModelServiceImpl.getProjectDataModel(DataModelServiceImpl.java:91)
> {code}
> The root cause is that kieModule.getPomModel() [here|https://github.com/kiegroup/drools/blob/master/kie-ci/src/main/java/org/kie/scanner/KieModuleMetaDataImpl.java#L167] returns null, because pom model is [not created in this case|https://github.com/kiegroup/drools/blob/master/drools-compiler/src/main/java/org/drools/compiler/kie/builder/impl/AbstractKieModule.java#L374-L388] because it can't be parsed or can't be validated.
> In this case we should at least avoid many NPEs being shown in server.log by doing null check and doing nothing if getPomModel() returns null



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

From issues at jboss.org  Wed Dec  6 09:57:00 2017
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Wed, 6 Dec 2017 09:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-183) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723786.1512572195000@Atlassian.JIRA>
References: <JIRA.12723786.1512572195000@Atlassian.JIRA>
	<JIRA.12723786.1512572195647@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723786.1512572195000.86018.1512572220800@Atlassian.JIRA>

Masafumi Miura created JBEE-183:
-----------------------------------

             Summary: NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
                 Key: JBEE-183
                 URL: https://issues.jboss.org/browse/JBEE-183
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
          Components: jboss-jstl-api
         Environment: - JBoss EAP 7.0.8
- jboss-jstl-api_1.2_spec-1.1.3.Final
            Reporter: Masafumi Miura
            Assignee: Scott Marlow


The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 

Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)

{code}
ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
    ...(snip)...
    ...
Caused by: java.lang.NullPointerException
    at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
    at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
    at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
    at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
    at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
    at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
    at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    ... 61 more
{code}



- https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277

{code}
252     public Object parseExpressionString(String pExpressionString)
253             throws ELException {
254         // See if it's an empty String
255         if (pExpressionString.length() == 0) {
256             return "";
257         }
258
259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
260             createExpressionStringMap();
261         }
262
263         // See if it's in the cache
264         Object ret =
265                 mBypassCache ?
266                         null :
267                         sCachedExpressionStrings.get(pExpressionString);
268
269         if (ret == null) {
270             // Parse the expression
271             Reader r = new StringReader(pExpressionString);
272             ELParser parser = new ELParser(r);
273             try {
274                 ret = parser.ExpressionString();
275                 if (!mBypassCache) {
276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
277                 }
278             }
279             catch (ParseException exc) {
280                 throw new ELException
281                         (formatParseException(pExpressionString,
282                                 exc));
283             }
284             catch (TokenMgrError exc) {
285                 // Note - this should never be reached, since the parser is
286                 // constructed to tokenize any input (illegal inputs get
287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
288                 // <ILLEGAL_CHARACTER>
289                 throw new ELException(exc.getMessage());
290             }
291         }
292         return ret;
293     }
{code}

- https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71

{code}
~~~
 51     /**
 52      * The singleton instance of the evaluator *
 53      */
 54     static ELEvaluator sEvaluator =
 55             new ELEvaluator
 56                     (new JSTLVariableResolver());
 :
 62     /**
 63      * Translation time validation of an attribute value.  This method
 64      * will return a null String if the attribute value is valid;
 65      * otherwise an error message.
 66      */
 67     public String validate(String pAttributeName,
 68                            String pAttributeValue) {
 69         try {
 70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
 71             sEvaluator.parseExpressionString(pAttributeValue);
 72             sEvaluator.setBypassCache(false);
 73             return null;
 74         }
 75         catch (ELException exc) {
{code}



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

From issues at jboss.org  Wed Dec  6 09:58:01 2017
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Wed, 6 Dec 2017 09:58:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-183) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723786.1512572196000@Atlassian.JIRA>
References: <JIRA.12723786.1512572196000@Atlassian.JIRA>
	<JIRA.12723786.1512572196000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723786.1512572196000.86082.1512572281422@Atlassian.JIRA>


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

Masafumi Miura updated JBEE-183:
--------------------------------
    Attachment: example.zip


> NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBEE-183
>                 URL: https://issues.jboss.org/browse/JBEE-183
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>         Environment: - JBoss EAP 7.0.8
> - jboss-jstl-api_1.2_spec-1.1.3.Final
>            Reporter: Masafumi Miura
>            Assignee: Scott Marlow
>         Attachments: byteman-script.btm, example.zip
>
>
> The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 
> Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)
> {code}
> ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
>     ...(snip)...
>     ...
> Caused by: java.lang.NullPointerException
>     at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
>     at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
>     at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
>     at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
>     at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
>     at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
>     at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     ... 61 more
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277
> {code}
> 252     public Object parseExpressionString(String pExpressionString)
> 253             throws ELException {
> 254         // See if it's an empty String
> 255         if (pExpressionString.length() == 0) {
> 256             return "";
> 257         }
> 258
> 259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
> 260             createExpressionStringMap();
> 261         }
> 262
> 263         // See if it's in the cache
> 264         Object ret =
> 265                 mBypassCache ?
> 266                         null :
> 267                         sCachedExpressionStrings.get(pExpressionString);
> 268
> 269         if (ret == null) {
> 270             // Parse the expression
> 271             Reader r = new StringReader(pExpressionString);
> 272             ELParser parser = new ELParser(r);
> 273             try {
> 274                 ret = parser.ExpressionString();
> 275                 if (!mBypassCache) {
> 276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
> 277                 }
> 278             }
> 279             catch (ParseException exc) {
> 280                 throw new ELException
> 281                         (formatParseException(pExpressionString,
> 282                                 exc));
> 283             }
> 284             catch (TokenMgrError exc) {
> 285                 // Note - this should never be reached, since the parser is
> 286                 // constructed to tokenize any input (illegal inputs get
> 287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
> 288                 // <ILLEGAL_CHARACTER>
> 289                 throw new ELException(exc.getMessage());
> 290             }
> 291         }
> 292         return ret;
> 293     }
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71
> {code}
> ~~~
>  51     /**
>  52      * The singleton instance of the evaluator *
>  53      */
>  54     static ELEvaluator sEvaluator =
>  55             new ELEvaluator
>  56                     (new JSTLVariableResolver());
>  :
>  62     /**
>  63      * Translation time validation of an attribute value.  This method
>  64      * will return a null String if the attribute value is valid;
>  65      * otherwise an error message.
>  66      */
>  67     public String validate(String pAttributeName,
>  68                            String pAttributeValue) {
>  69         try {
>  70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
>  71             sEvaluator.parseExpressionString(pAttributeValue);
>  72             sEvaluator.setBypassCache(false);
>  73             return null;
>  74         }
>  75         catch (ELException exc) {
> {code}



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

From issues at jboss.org  Wed Dec  6 09:58:01 2017
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Wed, 6 Dec 2017 09:58:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-183) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723786.1512572196000@Atlassian.JIRA>
References: <JIRA.12723786.1512572196000@Atlassian.JIRA>
	<JIRA.12723786.1512572196000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723786.1512572196000.86086.1512572281517@Atlassian.JIRA>


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

Masafumi Miura updated JBEE-183:
--------------------------------
    Attachment: byteman-script.btm


> NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBEE-183
>                 URL: https://issues.jboss.org/browse/JBEE-183
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>         Environment: - JBoss EAP 7.0.8
> - jboss-jstl-api_1.2_spec-1.1.3.Final
>            Reporter: Masafumi Miura
>            Assignee: Scott Marlow
>         Attachments: byteman-script.btm, example.zip
>
>
> The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 
> Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)
> {code}
> ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
>     ...(snip)...
>     ...
> Caused by: java.lang.NullPointerException
>     at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
>     at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
>     at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
>     at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
>     at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
>     at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
>     at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     ... 61 more
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277
> {code}
> 252     public Object parseExpressionString(String pExpressionString)
> 253             throws ELException {
> 254         // See if it's an empty String
> 255         if (pExpressionString.length() == 0) {
> 256             return "";
> 257         }
> 258
> 259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
> 260             createExpressionStringMap();
> 261         }
> 262
> 263         // See if it's in the cache
> 264         Object ret =
> 265                 mBypassCache ?
> 266                         null :
> 267                         sCachedExpressionStrings.get(pExpressionString);
> 268
> 269         if (ret == null) {
> 270             // Parse the expression
> 271             Reader r = new StringReader(pExpressionString);
> 272             ELParser parser = new ELParser(r);
> 273             try {
> 274                 ret = parser.ExpressionString();
> 275                 if (!mBypassCache) {
> 276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
> 277                 }
> 278             }
> 279             catch (ParseException exc) {
> 280                 throw new ELException
> 281                         (formatParseException(pExpressionString,
> 282                                 exc));
> 283             }
> 284             catch (TokenMgrError exc) {
> 285                 // Note - this should never be reached, since the parser is
> 286                 // constructed to tokenize any input (illegal inputs get
> 287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
> 288                 // <ILLEGAL_CHARACTER>
> 289                 throw new ELException(exc.getMessage());
> 290             }
> 291         }
> 292         return ret;
> 293     }
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71
> {code}
> ~~~
>  51     /**
>  52      * The singleton instance of the evaluator *
>  53      */
>  54     static ELEvaluator sEvaluator =
>  55             new ELEvaluator
>  56                     (new JSTLVariableResolver());
>  :
>  62     /**
>  63      * Translation time validation of an attribute value.  This method
>  64      * will return a null String if the attribute value is valid;
>  65      * otherwise an error message.
>  66      */
>  67     public String validate(String pAttributeName,
>  68                            String pAttributeValue) {
>  69         try {
>  70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
>  71             sEvaluator.parseExpressionString(pAttributeValue);
>  72             sEvaluator.setBypassCache(false);
>  73             return null;
>  74         }
>  75         catch (ELException exc) {
> {code}



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

From issues at jboss.org  Wed Dec  6 09:59:00 2017
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Wed, 6 Dec 2017 09:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-183) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723786.1512572196000@Atlassian.JIRA>
References: <JIRA.12723786.1512572196000@Atlassian.JIRA>
	<JIRA.12723786.1512572196000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723786.1512572196000.86097.1512572340484@Atlassian.JIRA>


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

Masafumi Miura updated JBEE-183:
--------------------------------


> NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBEE-183
>                 URL: https://issues.jboss.org/browse/JBEE-183
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>         Environment: - JBoss EAP 7.0.8
> - jboss-jstl-api_1.2_spec-1.1.3.Final
>            Reporter: Masafumi Miura
>            Assignee: Scott Marlow
>         Attachments: byteman-script.btm, example.zip
>
>
> The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 
> Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)
> {code}
> ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
>     ...(snip)...
>     ...
> Caused by: java.lang.NullPointerException
>     at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
>     at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
>     at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
>     at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
>     at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
>     at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
>     at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     ... 61 more
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277
> {code}
> 252     public Object parseExpressionString(String pExpressionString)
> 253             throws ELException {
> 254         // See if it's an empty String
> 255         if (pExpressionString.length() == 0) {
> 256             return "";
> 257         }
> 258
> 259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
> 260             createExpressionStringMap();
> 261         }
> 262
> 263         // See if it's in the cache
> 264         Object ret =
> 265                 mBypassCache ?
> 266                         null :
> 267                         sCachedExpressionStrings.get(pExpressionString);
> 268
> 269         if (ret == null) {
> 270             // Parse the expression
> 271             Reader r = new StringReader(pExpressionString);
> 272             ELParser parser = new ELParser(r);
> 273             try {
> 274                 ret = parser.ExpressionString();
> 275                 if (!mBypassCache) {
> 276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
> 277                 }
> 278             }
> 279             catch (ParseException exc) {
> 280                 throw new ELException
> 281                         (formatParseException(pExpressionString,
> 282                                 exc));
> 283             }
> 284             catch (TokenMgrError exc) {
> 285                 // Note - this should never be reached, since the parser is
> 286                 // constructed to tokenize any input (illegal inputs get
> 287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
> 288                 // <ILLEGAL_CHARACTER>
> 289                 throw new ELException(exc.getMessage());
> 290             }
> 291         }
> 292         return ret;
> 293     }
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71
> {code}
> ~~~
>  51     /**
>  52      * The singleton instance of the evaluator *
>  53      */
>  54     static ELEvaluator sEvaluator =
>  55             new ELEvaluator
>  56                     (new JSTLVariableResolver());
>  :
>  62     /**
>  63      * Translation time validation of an attribute value.  This method
>  64      * will return a null String if the attribute value is valid;
>  65      * otherwise an error message.
>  66      */
>  67     public String validate(String pAttributeName,
>  68                            String pAttributeValue) {
>  69         try {
>  70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
>  71             sEvaluator.parseExpressionString(pAttributeValue);
>  72             sEvaluator.setBypassCache(false);
>  73             return null;
>  74         }
>  75         catch (ELException exc) {
> {code}



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

From issues at jboss.org  Wed Dec  6 09:59:00 2017
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Wed, 6 Dec 2017 09:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-184) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723789.1512572328000@Atlassian.JIRA>
References: <JIRA.12723789.1512572328000@Atlassian.JIRA>
	<JIRA.12723789.1512572328163@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723789.1512572328000.86103.1512572340606@Atlassian.JIRA>

Masafumi Miura created JBEE-184:
-----------------------------------

             Summary: NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
                 Key: JBEE-184
                 URL: https://issues.jboss.org/browse/JBEE-184
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
          Components: jboss-jstl-api
         Environment: - JBoss EAP 7.0.8
- jboss-jstl-api_1.2_spec-1.1.3.Final
            Reporter: Masafumi Miura
            Assignee: Scott Marlow
         Attachments: byteman-script.btm, example.zip

The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 

Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)

{code}
ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
    ...(snip)...
    ...
Caused by: java.lang.NullPointerException
    at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
    at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
    at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
    at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
    at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
    at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
    at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    ... 61 more
{code}



- https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277

{code}
252     public Object parseExpressionString(String pExpressionString)
253             throws ELException {
254         // See if it's an empty String
255         if (pExpressionString.length() == 0) {
256             return "";
257         }
258
259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
260             createExpressionStringMap();
261         }
262
263         // See if it's in the cache
264         Object ret =
265                 mBypassCache ?
266                         null :
267                         sCachedExpressionStrings.get(pExpressionString);
268
269         if (ret == null) {
270             // Parse the expression
271             Reader r = new StringReader(pExpressionString);
272             ELParser parser = new ELParser(r);
273             try {
274                 ret = parser.ExpressionString();
275                 if (!mBypassCache) {
276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
277                 }
278             }
279             catch (ParseException exc) {
280                 throw new ELException
281                         (formatParseException(pExpressionString,
282                                 exc));
283             }
284             catch (TokenMgrError exc) {
285                 // Note - this should never be reached, since the parser is
286                 // constructed to tokenize any input (illegal inputs get
287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
288                 // <ILLEGAL_CHARACTER>
289                 throw new ELException(exc.getMessage());
290             }
291         }
292         return ret;
293     }
{code}

- https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71

{code}
~~~
 51     /**
 52      * The singleton instance of the evaluator *
 53      */
 54     static ELEvaluator sEvaluator =
 55             new ELEvaluator
 56                     (new JSTLVariableResolver());
 :
 62     /**
 63      * Translation time validation of an attribute value.  This method
 64      * will return a null String if the attribute value is valid;
 65      * otherwise an error message.
 66      */
 67     public String validate(String pAttributeName,
 68                            String pAttributeValue) {
 69         try {
 70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
 71             sEvaluator.parseExpressionString(pAttributeValue);
 72             sEvaluator.setBypassCache(false);
 73             return null;
 74         }
 75         catch (ELException exc) {
{code}



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

From issues at jboss.org  Wed Dec  6 10:25:04 2017
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Wed, 6 Dec 2017 10:25:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-183) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723786.1512572196000@Atlassian.JIRA>
References: <JIRA.12723786.1512572196000@Atlassian.JIRA>
	<JIRA.12723786.1512572196000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723786.1512572196000.86517.1512573904607@Atlassian.JIRA>


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

Masafumi Miura reassigned JBEE-183:
-----------------------------------

    Assignee:     (was: Scott Marlow)


> NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBEE-183
>                 URL: https://issues.jboss.org/browse/JBEE-183
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>         Environment: - JBoss EAP 7.0.8
> - jboss-jstl-api_1.2_spec-1.1.3.Final
>            Reporter: Masafumi Miura
>         Attachments: byteman-script.btm, example.zip
>
>
> The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 
> Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)
> {code}
> ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
>     ...(snip)...
>     ...
> Caused by: java.lang.NullPointerException
>     at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
>     at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
>     at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
>     at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
>     at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
>     at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
>     at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     ... 61 more
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277
> {code}
> 252     public Object parseExpressionString(String pExpressionString)
> 253             throws ELException {
> 254         // See if it's an empty String
> 255         if (pExpressionString.length() == 0) {
> 256             return "";
> 257         }
> 258
> 259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
> 260             createExpressionStringMap();
> 261         }
> 262
> 263         // See if it's in the cache
> 264         Object ret =
> 265                 mBypassCache ?
> 266                         null :
> 267                         sCachedExpressionStrings.get(pExpressionString);
> 268
> 269         if (ret == null) {
> 270             // Parse the expression
> 271             Reader r = new StringReader(pExpressionString);
> 272             ELParser parser = new ELParser(r);
> 273             try {
> 274                 ret = parser.ExpressionString();
> 275                 if (!mBypassCache) {
> 276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
> 277                 }
> 278             }
> 279             catch (ParseException exc) {
> 280                 throw new ELException
> 281                         (formatParseException(pExpressionString,
> 282                                 exc));
> 283             }
> 284             catch (TokenMgrError exc) {
> 285                 // Note - this should never be reached, since the parser is
> 286                 // constructed to tokenize any input (illegal inputs get
> 287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
> 288                 // <ILLEGAL_CHARACTER>
> 289                 throw new ELException(exc.getMessage());
> 290             }
> 291         }
> 292         return ret;
> 293     }
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71
> {code}
> ~~~
>  51     /**
>  52      * The singleton instance of the evaluator *
>  53      */
>  54     static ELEvaluator sEvaluator =
>  55             new ELEvaluator
>  56                     (new JSTLVariableResolver());
>  :
>  62     /**
>  63      * Translation time validation of an attribute value.  This method
>  64      * will return a null String if the attribute value is valid;
>  65      * otherwise an error message.
>  66      */
>  67     public String validate(String pAttributeName,
>  68                            String pAttributeValue) {
>  69         try {
>  70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
>  71             sEvaluator.parseExpressionString(pAttributeValue);
>  72             sEvaluator.setBypassCache(false);
>  73             return null;
>  74         }
>  75         catch (ELException exc) {
> {code}



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

From issues at jboss.org  Wed Dec  6 10:43:00 2017
From: issues at jboss.org (Sven Geisenhainer (JIRA))
Date: Wed, 6 Dec 2017 10:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9599) Unable to suspend server
 using management console with timeout -1
In-Reply-To: <JIRA.12723804.1512574932000@Atlassian.JIRA>
References: <JIRA.12723804.1512574932000@Atlassian.JIRA>
	<JIRA.12723804.1512574932397@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723804.1512574932000.86910.1512574980424@Atlassian.JIRA>

Sven Geisenhainer created WFLY-9599:
---------------------------------------

             Summary: Unable to suspend server using management console with timeout -1
                 Key: WFLY-9599
                 URL: https://issues.jboss.org/browse/WFLY-9599
             Project: WildFly
          Issue Type: Bug
          Components: Web Console
    Affects Versions: 11.0.0.Final
            Reporter: Sven Geisenhainer
            Assignee: Harald Pehl
         Attachments: screenshot.jpg

Supending the server using the web console with timeout value -1 (should cause the server to wait indefinitely for all active requests to complete) is not possible, error message: "Value must be between 0 and 9007199254740991" - see  !screenshot.jpg|thumbnail! 



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

From issues at jboss.org  Wed Dec  6 10:50:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 6 Dec 2017 10:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1459) Move byte and codepoint
 iterators to WildFly Common
In-Reply-To: <JIRA.12723806.1512575357000@Atlassian.JIRA>
References: <JIRA.12723806.1512575357000@Atlassian.JIRA>
	<JIRA.12723806.1512575357637@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723806.1512575357000.86955.1512575400387@Atlassian.JIRA>

David Lloyd created ELY-1459:
--------------------------------

             Summary: Move byte and codepoint iterators to WildFly Common
                 Key: ELY-1459
                 URL: https://issues.jboss.org/browse/ELY-1459
             Project: WildFly Elytron
          Issue Type: Task
          Components: Utils
            Reporter: David Lloyd


This is the partner issue to WFCOM-25.

There is a need or desire to open up the byte/code point iteration API, but the natural tension is that it is not really security related.  At the same time, this kind of code is duplicated in a few other places.  Moving these classes to WildFly Common would solve several problems at once.

This issue should serve as a point of discussion for this idea.



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

From issues at jboss.org  Wed Dec  6 11:02:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 6 Dec 2017 11:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6458) JavaMail 1.6 Support
In-Reply-To: <JIRA.12612933.1459635518000@Atlassian.JIRA>
References: <JIRA.12612933.1459635518000@Atlassian.JIRA>
	<JIRA.12612933.1459635518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12612933.1459635518000.87319.1512576120254@Atlassian.JIRA>


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

Tomaz Cerar reassigned WFLY-6458:
---------------------------------

    Assignee: Tomaz Cerar


> JavaMail 1.6 Support
> --------------------
>
>                 Key: WFLY-6458
>                 URL: https://issues.jboss.org/browse/WFLY-6458
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Mail
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>




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

From issues at jboss.org  Wed Dec  6 11:06:00 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Wed, 6 Dec 2017 11:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.87349.1512576360306@Atlassian.JIRA>


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

Alberto Gori updated ELY-1455:
------------------------------
    Attachment: wmt-elytron.war


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 11:06:00 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Wed, 6 Dec 2017 11:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.87354.1512576360424@Atlassian.JIRA>


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

Alberto Gori updated ELY-1455:
------------------------------
    Attachment: elytron-bug-src.zip


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 11:10:01 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Wed, 6 Dec 2017 11:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.87403.1512576601417@Atlassian.JIRA>


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

Alberto Gori commented on ELY-1455:
-----------------------------------

Done (war and zip containing sources). It's a very basic JSF application using RichFaces and PrettyFaces.

If you enable mysql logs, you'll see the duplicated queries everytime you reload the page after a successful login (wmtadmin/dashboard) 

Let me know if this is not the case.



>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 11:18:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 6 Dec 2017 11:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.87482.1512577080406@Atlassian.JIRA>


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

Darran Lofthouse reassigned ELY-1455:
-------------------------------------

    Assignee: Darran Lofthouse


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 11:19:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 6 Dec 2017 11:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3451) Minor cleanups in
 org.jboss.as.controller.ModelVersion
In-Reply-To: <JIRA.12723813.1512577100000@Atlassian.JIRA>
References: <JIRA.12723813.1512577100000@Atlassian.JIRA>
	<JIRA.12723813.1512577100726@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723813.1512577100000.87488.1512577140294@Atlassian.JIRA>

David Lloyd created WFCORE-3451:
-----------------------------------

             Summary: Minor cleanups in org.jboss.as.controller.ModelVersion
                 Key: WFCORE-3451
                 URL: https://issues.jboss.org/browse/WFCORE-3451
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: David Lloyd
            Assignee: David Lloyd
            Priority: Optional


I was in the neighborhood and happened to notice some code quirks and missing validations in org.jboss.as.controller.ModelVersion.



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

From issues at jboss.org  Wed Dec  6 11:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5038) Update MutableDetector to
 include immutable classes introduced in Java 8
In-Reply-To: <JIRA.12579867.1438264304000@Atlassian.JIRA>
References: <JIRA.12579867.1438264304000@Atlassian.JIRA>
	<JIRA.12579867.1438264304000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579867.1438264304000.87517.1512577224896@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5038.
----------------------------


> Update MutableDetector to include immutable classes introduced in Java 8
> ------------------------------------------------------------------------
>
>                 Key: WFLY-5038
>                 URL: https://issues.jboss.org/browse/WFLY-5038
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta1
>
>
> e.g.
> java.time.*



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

From issues at jboss.org  Wed Dec  6 11:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4659) Upgrade JGroups to 3.6.3.Final
In-Reply-To: <JIRA.12572436.1432238965000@Atlassian.JIRA>
References: <JIRA.12572436.1432238965000@Atlassian.JIRA>
	<JIRA.12572436.1432238965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572436.1432238965000.87499.1512577224033@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4659.
----------------------------


> Upgrade JGroups to 3.6.3.Final
> ------------------------------
>
>                 Key: WFLY-4659
>                 URL: https://issues.jboss.org/browse/WFLY-4659
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha2
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4534) Nightly build fails with
	Maven 3.3.1
In-Reply-To: <JIRA.12568750.1429294786000@Atlassian.JIRA>
References: <JIRA.12568750.1429294786000@Atlassian.JIRA>
	<JIRA.12568750.1429294786000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568750.1429294786000.87506.1512577224443@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4534.
----------------------------


> Nightly build fails with Maven 3.3.1
> ------------------------------------
>
>                 Key: WFLY-4534
>                 URL: https://issues.jboss.org/browse/WFLY-4534
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 9.0.0.Beta2
>         Environment: Kubuntu Linux & OS X 10.10.3, Maven 3.3.1
>            Reporter: Peter Major
>            Assignee: James Perkins
>             Fix For: 10.0.0.Alpha1
>
>
> When trying to build 78099bb2fc with Maven 3.3.1 I get the following error from maven-enforcer plugin (at wildfly-feature-pack module):
> {noformat}
> [INFO] Building WildFly: Full Feature Pack 9.0.0.CR1-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO] 
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ wildfly-feature-pack ---
> [INFO] 
> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (ban-bad-dependencies) @ wildfly-feature-pack ---
> [INFO] 
> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @ wildfly-feature-pack ---
> [INFO] 
> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @ wildfly-feature-pack ---
> [INFO] 
> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (ban-transitive-deps) @ wildfly-feature-pack ---
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with message:
> org.wildfly:wildfly-feature-pack:pom:9.0.0.CR1-SNAPSHOT
>    org.wildfly:wildfly-client-all:jar:9.0.0.CR1-SNAPSHOT:compile has transitive dependencies:
>       org.jboss.remotingjmx:remoting-jmx:jar:2.0.1.CR2:compile
>          org.jboss.logging:jboss-logging:jar:3.2.1.Final:compile
>          org.jboss.marshalling:jboss-marshalling:jar:1.4.10.Final:compile
>          org.jboss.marshalling:jboss-marshalling-river:jar:1.4.10.Final:compile
>          org.jboss.remoting:jboss-remoting:jar:4.0.8.Final:compile
>          org.jboss.sasl:jboss-sasl:jar:1.0.5.Final:compile
>          org.jboss.xnio:xnio-api:jar:3.3.1.Final:compile
>          org.jboss.xnio:xnio-nio:jar:3.3.1.Final:compile
> {noformat}
> Oddly enough if you run {{mvn clean install -rf :wildfly-feature-pack}} then the build succeeds for the module..
> I did try to specify {{-Dversion.enforcer.plugin=1.4}}, but that didn't help. 



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

From issues at jboss.org  Wed Dec  6 11:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4849) Messaging transformer tests
 are failing with a CNFE
In-Reply-To: <JIRA.12576678.1435697968000@Atlassian.JIRA>
References: <JIRA.12576678.1435697968000@Atlassian.JIRA>
	<JIRA.12576678.1435697968000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576678.1435697968000.87512.1512577224641@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4849.
----------------------------


> Messaging transformer tests are failing with a CNFE
> ---------------------------------------------------
>
>                 Key: WFLY-4849
>                 URL: https://issues.jboss.org/browse/WFLY-4849
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: James Perkins
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> When running {{legacy/messages}} subsystem tests with {{-Djboss.test.transformers.eap}} fail. Two fail with a {{ClassNotFoundException}} and two fail assertions. See http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=58617&buildTypeId=WF_MasterLinux&tab=buildResultsDiv for details.
> For now I'll {{@Ignore}} the tests.



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

From issues at jboss.org  Wed Dec  6 11:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3771) Implement graceful shutdown
	for clustering
In-Reply-To: <JIRA.12550191.1409027730000@Atlassian.JIRA>
References: <JIRA.12550191.1409027730000@Atlassian.JIRA>
	<JIRA.12550191.1409027730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12550191.1409027730000.87523.1512577225159@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3771.
----------------------------


> Implement graceful shutdown for clustering
> ------------------------------------------
>
>                 Key: WFLY-3771
>                 URL: https://issues.jboss.org/browse/WFLY-3771
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>            Reporter: Stuart Douglas
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta1
>
>
> I am not sure exactly what needs to happen here, I think all that is required is for the node to leave the cluster before suspend starts. 



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

From issues at jboss.org  Wed Dec  6 11:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5174) Upgrade jberet-core to
	1.2.0.Beta1
In-Reply-To: <JIRA.12582241.1440212259000@Atlassian.JIRA>
References: <JIRA.12582241.1440212259000@Atlassian.JIRA>
	<JIRA.12582241.1440212259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582241.1440212259000.87529.1512577225400@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5174.
----------------------------


> Upgrade jberet-core to 1.2.0.Beta1
> ----------------------------------
>
>                 Key: WFLY-5174
>                 URL: https://issues.jboss.org/browse/WFLY-5174
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Batch
>            Reporter: Cheng Fang
>            Assignee: James Perkins
>             Fix For: 10.0.0.CR1
>
>
> JBeret 1.2.0.Beta1:
> https://issues.jboss.org/browse/JBERET/fixforversion/12327647/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel



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

From issues at jboss.org  Wed Dec  6 11:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4745) Mixed domain tests don't work
	on ipv6
In-Reply-To: <JIRA.12573858.1433412262000@Atlassian.JIRA>
References: <JIRA.12573858.1433412262000@Atlassian.JIRA>
	<JIRA.12573858.1433412262000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573858.1433412262000.87532.1512577225616@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4745.
----------------------------


> Mixed domain tests don't work on ipv6
> -------------------------------------
>
>                 Key: WFLY-4745
>                 URL: https://issues.jboss.org/browse/WFLY-4745
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 10.0.0.Alpha4
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5098) Graceful shutdown doesn't
 work with WebSockets
In-Reply-To: <JIRA.12581101.1439462907000@Atlassian.JIRA>
References: <JIRA.12581101.1439462907000@Atlassian.JIRA>
	<JIRA.12581101.1439462907000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581101.1439462907000.87536.1512577225792@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5098.
----------------------------


> Graceful shutdown doesn't work with WebSockets
> ----------------------------------------------
>
>                 Key: WFLY-5098
>                 URL: https://issues.jboss.org/browse/WFLY-5098
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.Beta2
>
>
> When sending websocket message, which is being processed for a longer time on server side and calling graceful shutdown, it doesn't wait for the message already being processed to be finished.



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

From issues at jboss.org  Wed Dec  6 11:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5275) Connection Factory parameter
 disappears after code deployment
In-Reply-To: <JIRA.12583917.1441317082000@Atlassian.JIRA>
References: <JIRA.12583917.1441317082000@Atlassian.JIRA>
	<JIRA.12583917.1441317082000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583917.1441317082000.87542.1512577226053@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5275.
----------------------------


> Connection Factory parameter disappears after code deployment
> -------------------------------------------------------------
>
>                 Key: WFLY-5275
>                 URL: https://issues.jboss.org/browse/WFLY-5275
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Mike Millson
>            Assignee: Chao Wang
>             Fix For: 10.0.0.CR1
>
>
> The min-pool-size setting in the following connection Factory disappears from domain.xml after any code deployments or change made in the console to the queues for the connection factory:
> {code}
> <connection-definition class-name="org.apache.activemq.ra.ActiveMQManagedConnectionFactory" jndi-name="java:jboss/activemq/XAConnectionFactory" enabled="true" use-java-context="true" pool-name="ConnectionFactory" min-pool-size="0"></connection>
> {code}



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

From issues at jboss.org  Wed Dec  6 11:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5002) Undertow mod_cluster CLI:
 Display node's Flushpackets, Flushwait, Ping, Smax and Ttl properties
In-Reply-To: <JIRA.12578742.1437479973000@Atlassian.JIRA>
References: <JIRA.12578742.1437479973000@Atlassian.JIRA>
	<JIRA.12578742.1437479973000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578742.1437479973000.87547.1512577226391@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5002.
----------------------------


> Undertow mod_cluster CLI: Display node's Flushpackets, Flushwait, Ping, Smax and Ttl properties
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5002
>                 URL: https://issues.jboss.org/browse/WFLY-5002
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Michal Karm Babacek
>            Assignee: Stuart Douglas
>              Labels: mod_cluster
>             Fix For: 10.0.0.Alpha6
>
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Display node's Flushpackets, Flushwait, Ping, Smax and Ttl properties
> At the moment, this is all there is to see:
> {noformat}
> "balancer" => {
>     "qa_balancer" => {"node" => {"worker-2" => {
>         "load" => 89,
>         "status" => "NODE_UP",
>         "context" => {"/clusterbench" => {
>             "requests" => 0,
>             "status" => "enabled"
>         }}
>     }}},
> ...
> {noformat}
> h3. Call to action
> For any serious enterprise deployment, users need to tweak at least ping and ttl attributes and they will need to be able to see their values on Undertow mod_cluster proxy balancer CLI console per each worker.



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

From issues at jboss.org  Wed Dec  6 11:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4856) failing legacy messaging
	transformer tests
In-Reply-To: <JIRA.12576857.1435823595000@Atlassian.JIRA>
References: <JIRA.12576857.1435823595000@Atlassian.JIRA>
	<JIRA.12576857.1435823595000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576857.1435823595000.87552.1512577226654@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4856.
----------------------------


> failing legacy messaging transformer tests
> ------------------------------------------
>
>                 Key: WFLY-4856
>                 URL: https://issues.jboss.org/browse/WFLY-4856
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> When running {{legacy/messages}} subsystem tests with {{-Djboss.test.transformers.eap}} fail. Two testTransformersEPA_X_X_X fail assertions. See http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=58617&buildTypeId=WF_MasterLinux&tab=buildResultsDiv for details.



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

From issues at jboss.org  Wed Dec  6 11:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4624) JGroups protocol properties
 are not applied
In-Reply-To: <JIRA.12571339.1431372527000@Atlassian.JIRA>
References: <JIRA.12571339.1431372527000@Atlassian.JIRA>
	<JIRA.12571339.1431372527000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571339.1431372527000.87558.1512577226959@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4624.
----------------------------


> JGroups protocol properties are not applied
> -------------------------------------------
>
>                 Key: WFLY-4624
>                 URL: https://issues.jboss.org/browse/WFLY-4624
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1
>            Reporter: Farah Juma
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> Protocol properties are never applied, the check for applying properties is done on the legacy resource that only registers operation tranformation on old the old property address.
> Original report:
> ----
> When the JGroups subsystem is configured to use TCPPING, the following error occurs when deploying a distributable app:
> {code}
> 14:50:11,930 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of initial_hosts in TCPPING with original property value null and converted to null could not be assigned
> 	at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:79)
> 	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.PrivilegedActionException: java.lang.Exception: Property assignment of initial_hosts in TCPPING with original property value null and converted to null could not be assigned
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:638)
> 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:99)
> 	at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:77)
> 	... 5 more
> Caused by: java.lang.Exception: Property assignment of initial_hosts in TCPPING with original property value null and converted to null could not be assigned
> 	at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> 	at org.jgroups.JChannel.init(JChannel.java:854)
> 	at org.jgroups.JChannel.<init>(JChannel.java:159)
> 	at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:96)
> 	at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:93)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:634)
> 	... 7 more
> Caused by: java.lang.Exception: Conversion of initial_hosts in TCPPING with original property value null failed
> 	at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> 	at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> 	... 17 more
> Caused by: java.lang.NullPointerException
> 	at java.util.StringTokenizer.<init>(StringTokenizer.java:199)
> 	at java.util.StringTokenizer.<init>(StringTokenizer.java:221)
> 	at org.jgroups.util.Util.parseCommaDelimitedHosts(Util.java:2650)
> 	at org.jgroups.conf.PropertyConverters$InitialHosts.convert(PropertyConverters.java:67)
> 	at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:81)
> 	... 18 more
> {code}



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

From issues at jboss.org  Wed Dec  6 11:20:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4774) Change build process to
 generate host.xml files from subsystem templates
In-Reply-To: <JIRA.12574841.1434115974000@Atlassian.JIRA>
References: <JIRA.12574841.1434115974000@Atlassian.JIRA>
	<JIRA.12574841.1434115974000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574841.1434115974000.87561.1512577227117@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4774.
----------------------------


> Change build process to generate host.xml files from subsystem templates
> ------------------------------------------------------------------------
>
>                 Key: WFLY-4774
>                 URL: https://issues.jboss.org/browse/WFLY-4774
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>              Labels: affects_elytron
>             Fix For: 10.0.0.Alpha4
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4264) Update ejb-client version to
	2.1.1.Final
In-Reply-To: <JIRA.12561171.1421671619000@Atlassian.JIRA>
References: <JIRA.12561171.1421671619000@Atlassian.JIRA>
	<JIRA.12561171.1421671619000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561171.1421671619000.87566.1512577227469@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4264.
----------------------------


> Update ejb-client version to 2.1.1.Final
> ----------------------------------------
>
>                 Key: WFLY-4264
>                 URL: https://issues.jboss.org/browse/WFLY-4264
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: EJB
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: David Lloyd
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4833) Upgrade wildfly-arquillian
 from 1.0.0.CR1 to 1.0.0.Final
In-Reply-To: <JIRA.12576354.1435282832000@Atlassian.JIRA>
References: <JIRA.12576354.1435282832000@Atlassian.JIRA>
	<JIRA.12576354.1435282832000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576354.1435282832000.87569.1512577227536@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4833.
----------------------------


> Upgrade wildfly-arquillian from 1.0.0.CR1 to 1.0.0.Final
> --------------------------------------------------------
>
>                 Key: WFLY-4833
>                 URL: https://issues.jboss.org/browse/WFLY-4833
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Test Suite
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5255) EJB3 needs transformers for
	EAP 6.4.0
In-Reply-To: <JIRA.12583483.1441134232000@Atlassian.JIRA>
References: <JIRA.12583483.1441134232000@Atlassian.JIRA>
	<JIRA.12583483.1441134232000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583483.1441134232000.87572.1512577227719@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5255.
----------------------------


> EJB3 needs transformers for EAP 6.4.0
> -------------------------------------
>
>                 Key: WFLY-5255
>                 URL: https://issues.jboss.org/browse/WFLY-5255
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5076) Enhance testsuite with
	WS-Trust/STS tests
In-Reply-To: <JIRA.12580870.1439305156000@Atlassian.JIRA>
References: <JIRA.12580870.1439305156000@Atlassian.JIRA>
	<JIRA.12580870.1439305156000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580870.1439305156000.87576.1512577227853@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5076.
----------------------------


> Enhance testsuite with WS-Trust/STS tests
> -----------------------------------------
>
>                 Key: WFLY-5076
>                 URL: https://issues.jboss.org/browse/WFLY-5076
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Jan Bliz??k
>            Assignee: Jan Bliz??k
>             Fix For: 10.0.0.CR1
>
>
> Port WS-Trust tests from JBossWS testsuite, try to reuse as much as possible.



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


From issues at jboss.org  Wed Dec  6 11:20:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4695) Remove infinispan-query
 module and its dependencies
In-Reply-To: <JIRA.12573128.1432817999000@Atlassian.JIRA>
References: <JIRA.12573128.1432817999000@Atlassian.JIRA>
	<JIRA.12573128.1432817999000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573128.1432817999000.87587.1512577228602@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4695.
----------------------------


> Remove infinispan-query module and its dependencies
> ---------------------------------------------------
>
>                 Key: WFLY-4695
>                 URL: https://issues.jboss.org/browse/WFLY-4695
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Sanne Grinovero
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta1
>
>
> We generally expect people to use the version bundled by the Infinispan project, and there are no strong reasons to include this in WildFly.
> Also it makes it much harder to upgrade components such as Hibernate and Infinispan as this components introduces strong coupling on several of these components, essentially mandating that these are all upgraded in lock step.



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

From issues at jboss.org  Wed Dec  6 11:20:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4839) annotation must be scanned
 regardless of the version of web.xml unless metadata-complete is explicitly
 set to true
In-Reply-To: <JIRA.12576450.1435568947000@Atlassian.JIRA>
References: <JIRA.12576450.1435568947000@Atlassian.JIRA>
	<JIRA.12576450.1435568947000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576450.1435568947000.87592.1512577228858@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4839.
----------------------------


> annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4839
>                 URL: https://issues.jboss.org/browse/WFLY-4839
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>             Fix For: 10.0.0.Beta2
>
>
> {noformat}
> ### Description of problem:
> Annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true.
> Note that Servlet 3.0 specification clearly states the following:
> ~~~
> 1.6.2 Processing annotations
> In Servlet 2.5, metadata-complete only affected the scanning of annotations at
> deployment time. The notion of web-fragments did not exist in servlet 2.5. However
> in servlet 3.0 metadata-complete affects scanning of all annotations and web-
> fragments at deployment time. The version of the descriptor MUST not affect which
> annotations you scan for in a web application. An implementation of a particular
> version of the specification MUST scan for all annotations supported in that
> configuration, unless metadata-complete is specified.
> ~~~
> ### How reproducible:
> Anytime
> ### Steps to Reproduce:
> 1. Create a library jar which contains a servlet filter using @WebFilter 
> 2. Put the jar under WEB-INF/lib of the web application which web.xml version is 2.3 or 2.4
> 3. Start JBoss EAP 6
> 4. Access the web application and see if the servlet filter works
> ### Actual results:
> The servlet filter is not invoked
> ### Expected results:
> The servlet filter is invoked
> ### Additional info:
> It works when the version of web.xml is 2.5 or 3.0
> [reply] [?]
> Private
> Comment 1 Masafumi Miura 2015-06-25 07:18:17 EDT
> RED HAT CONFIDENTIAL
> It looks metadata-complete is always set to true when the version of web.xml is 2.3 or 2.4 at the line 96 of web/src/main/java/org/jboss/as/web/deployment/WarMetaDataProcessor.java.
> Though Servlet 2.3/2.3 specification does not have metadata-complete attribute, Servlet 3.0 specification states the following. I think it means that the metadata-complete attribute default to false if it is not specified.
> ~~~
> 8.1 Annotations and pluggability
> if the metadata-complete attribute is not specified or is set to "false", the
> deployment tool must examine the class files of the application for annotations, and
> scan for web fragments.
> ~~~
>  * web/src/main/java/org/jboss/as/web/deployment/WarMetaDataProcessor.java
>  76 public class WarMetaDataProcessor implements DeploymentUnitProcessor {
>  77 
>  78     @Override
>  79     public void deploy(DeploymentPhaseContext phaseContext) throws DeploymentUnitProcessingException {
> ...
>  87         boolean isComplete = false;
>  88         WebMetaData specMetaData = warMetaData.getWebMetaData();
>  89         if (specMetaData != null) {
>  90             if (specMetaData instanceof Web25MetaData) {
>  91                 isComplete |= ((Web25MetaData) specMetaData).isMetadataComplete();
>  92             } else if (specMetaData instanceof Web30MetaData) {
>  93                 isComplete |= ((Web30MetaData) specMetaData).isMetadataComplete();
>  94             } else {
>  95                 // Any web.xml 2.4 or earlier deployment is metadata complete
>  96                 isComplete = true;
>  97             }
>  98         }
>  99
> {noformat}



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


From issues at jboss.org  Wed Dec  6 11:20:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4670) Term 'jacorb' is part of xml
 configuration file despite of fact being replaced by IIOP orb
In-Reply-To: <JIRA.12572567.1432546165000@Atlassian.JIRA>
References: <JIRA.12572567.1432546165000@Atlassian.JIRA>
	<JIRA.12572567.1432546165000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572567.1432546165000.87596.1512577228936@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4670.
----------------------------


> Term 'jacorb' is part of xml configuration file despite of fact being replaced by IIOP orb
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4670
>                 URL: https://issues.jboss.org/browse/WFLY-4670
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Minor
>             Fix For: 10.0.0.Alpha2
>
>
> Implementation of ORB - JacORB is replaced by JDK ORB in WildFly 10. Neverhteless server xml configuration files contain term 'jacorb' at several places.
> Should not be word 'jacorb' removed from xml configuration and replaced by term 'iiop orb'?
> Examples of occurrence
> {code}
>         <!-- TODO - only show this if the jacorb subsystem is added  -->
>         <interface name="unsecure">
>             <!--
>               ~  Used for IIOP sockets in the standard configuration.
>               ~                  To secure JacORB you need to setup SSL 
>               -->
>             <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
>         </interface>
> {code}
> {code}
>             <logger category="jacorb">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="jacorb.config">
>                 <level name="ERROR"/>
>             </logger>
> {code}



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

From issues at jboss.org  Wed Dec  6 11:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5153) IIOP migrate operation does
 not translate ior-settings
In-Reply-To: <JIRA.12582095.1440144442000@Atlassian.JIRA>
References: <JIRA.12582095.1440144442000@Atlassian.JIRA>
	<JIRA.12582095.1440144442000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582095.1440144442000.87600.1512577229014@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5153.
----------------------------


> IIOP migrate operation does not translate ior-settings
> ------------------------------------------------------
>
>                 Key: WFLY-5153
>                 URL: https://issues.jboss.org/browse/WFLY-5153
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>             Fix For: 10.0.0.CR1
>
>
> Ior-settings is not migrated in current time despite the fact that their values seem to be valid for migration.
> If I have JacORB configuration like
> {code}
> <subsystem xmlns="urn:jboss:domain:jacorb:1.4">
>     <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
>         <initializers security="identity" transactions="on"/>
>     </orb>
>     <security client-requires="ServerAuth" server-supports="ServerAuth" server-requires="ServerAuth"/>
>     <ior-settings>
>         <transport-config integrity="required" confidentiality="supported" trust-in-client="required" trust-in-target="supported" "
>             detect-replay="required" detect-misordering="required"/>
>         <as-context auth-method="none"/>
>         <sas-context caller-propagation="supported"/>
>     </ior-settings>
> </subsystem>
> {code}
> The migration output will be 
> {code}
>         <subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
>             <orb ssl-socket-binding="jacorb-ssl" socket-binding="jacorb"/>
>             <initializers transactions="full" security="identity"/>
>             <security server-requires="ServerAuth" server-supports="ServerAuth" client-requires="ServerAuth"/>
>         </subsystem>
> {code}
> but I would rather expect output like
> {code}
> <subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
>     <orb ssl-socket-binding="jacorb-ssl" socket-binding="jacorb"/>
>     <initializers transactions="full" security="identity"/>
>     <security server-requires="ServerAuth" server-supports="ServerAuth" client-requires="ServerAuth" client-supports="ServerAuth"/>
>     <transport-config detect-misordering="required" detect-replay="required" trust-in-client="required" trust-in-target="supported" confidentiality="supported" integrity="required"/>
>     <as-context auth-method="none"/>
> </subsystem>
> {code}



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

From issues at jboss.org  Wed Dec  6 11:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4688) Update to HAL 2.6.10
In-Reply-To: <JIRA.12572975.1432733144000@Atlassian.JIRA>
References: <JIRA.12572975.1432733144000@Atlassian.JIRA>
	<JIRA.12572975.1432733144000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572975.1432733144000.87603.1512577229089@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4688.
----------------------------


> Update to HAL 2.6.10
> --------------------
>
>                 Key: WFLY-4688
>                 URL: https://issues.jboss.org/browse/WFLY-4688
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha2
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5204) Setting mod_cluster advertise
 frequency to zero does not disable advertise
In-Reply-To: <JIRA.12582606.1440547865000@Atlassian.JIRA>
References: <JIRA.12582606.1440547865000@Atlassian.JIRA>
	<JIRA.12582606.1440547865000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582606.1440547865000.87607.1512577229300@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5204.
----------------------------


> Setting mod_cluster advertise frequency to zero does not disable advertise
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5204
>                 URL: https://issues.jboss.org/browse/WFLY-5204
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4575) Use
 Flag.RESTART_RESOURCE_SERVICES for child resources of stack/channel
In-Reply-To: <JIRA.12570504.1430481247000@Atlassian.JIRA>
References: <JIRA.12570504.1430481247000@Atlassian.JIRA>
	<JIRA.12570504.1430481247000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570504.1430481247000.87612.1512577229495@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4575.
----------------------------


> Use Flag.RESTART_RESOURCE_SERVICES for child resources of stack/channel
> -----------------------------------------------------------------------
>
>                 Key: WFLY-4575
>                 URL: https://issues.jboss.org/browse/WFLY-4575
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta1
>
>
> Currently, the attributes for each child resource of a stack or channel use RESTART_ALL_SERVICES, thus any change to one of these attributes requires all services to restart.  This is overkill, since only the services of the parent resource (i.e. channel, channel factory) actually require restarting.



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

From issues at jboss.org  Wed Dec  6 11:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5223) Upgrade JSoup version to 1.8.3
In-Reply-To: <JIRA.12583014.1440683554000@Atlassian.JIRA>
References: <JIRA.12583014.1440683554000@Atlassian.JIRA>
	<JIRA.12583014.1440683554000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583014.1440683554000.87615.1512577229599@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5223.
----------------------------


> Upgrade JSoup version to 1.8.3
> ------------------------------
>
>                 Key: WFLY-5223
>                 URL: https://issues.jboss.org/browse/WFLY-5223
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Hardy Ferentschik
>            Assignee: Hardy Ferentschik
>             Fix For: 10.0.0.CR1
>
>
> Upgrade JSoup version to avoid treating invalid HTML as valid using Hibernate Validator's {{SafeHtml}}, when '>' missing at EOF. See https://hibernate.atlassian.net/browse/HV-1012 and https://github.com/jhy/jsoup/pull/582



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

From issues at jboss.org  Wed Dec  6 11:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4980) IronJacamar 1.2.5.Final
In-Reply-To: <JIRA.12578781.1437488175000@Atlassian.JIRA>
References: <JIRA.12578781.1437488175000@Atlassian.JIRA>
	<JIRA.12578781.1437488175000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578781.1437488175000.87618.1512577229779@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4980.
----------------------------


> IronJacamar 1.2.5.Final
> -----------------------
>
>                 Key: WFLY-4980
>                 URL: https://issues.jboss.org/browse/WFLY-4980
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 10.0.0.Alpha6
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4898) Change in permissions is not
 visible until server reload
In-Reply-To: <JIRA.12577579.1436450900000@Atlassian.JIRA>
References: <JIRA.12577579.1436450900000@Atlassian.JIRA>
	<JIRA.12577579.1436450900000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577579.1436450900000.87625.1512577230082@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4898.
----------------------------


> Change in permissions is not visible until server reload
> --------------------------------------------------------
>
>                 Key: WFLY-4898
>                 URL: https://issues.jboss.org/browse/WFLY-4898
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security Manager
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Josef Cacek
>            Assignee: Tomas Hofman
>             Fix For: 10.0.0.Alpha6
>
>
> When adding permissions in the security-manager subsystem, the changes are not used until server reload. But the CLI operation *doesn't require reload*.



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

From issues at jboss.org  Wed Dec  6 11:20:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4716) Remove temporary code
 following core release
In-Reply-To: <JIRA.12573495.1433227668000@Atlassian.JIRA>
References: <JIRA.12573495.1433227668000@Atlassian.JIRA>
	<JIRA.12573495.1433227668000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573495.1433227668000.87628.1512577230136@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4716.
----------------------------


> Remove temporary code following core release
> --------------------------------------------
>
>                 Key: WFLY-4716
>                 URL: https://issues.jboss.org/browse/WFLY-4716
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 10.0.0.Alpha3
>
>
> PR #7555 is the one introducing the temporary code. It prepares for the core release by implementing the new introduced methods, but comments out the @Override annotations so it will compile before the core release is made.
> The follow-up work will be to re-add these annotations, which have all been commented out as 
> {code}
> //@Override WFLY-4716
> {code}
>  and adjustments to AppClientXml
> {code}
> --- a/appclient/src/main/java/org/jboss/as/appclient/subsystem/parsing/AppClientXml.java
> +++ b/appclient/src/main/java/org/jboss/as/appclient/subsystem/parsing/AppClientXml.java
> @@ -54,8 +54,9 @@ import org.jboss.as.controller.parsing.ExtensionXml;
>  import org.jboss.as.controller.parsing.Namespace;
>  import org.jboss.as.controller.parsing.ParseUtils;
>  import org.jboss.as.controller.persistence.ModelMarshallingContext;
> -import org.jboss.as.controller.resource.SocketBindingGroupResourceDefinition;
>  import org.jboss.as.server.parsing.CommonXml;
> +import org.jboss.as.server.parsing.SocketBindingsXml;
> +import org.jboss.as.server.services.net.SocketBindingGroupResourceDefinition;
>  import org.jboss.dmr.ModelNode;
>  import org.jboss.dmr.Property;
>  import org.jboss.modules.ModuleLoader;
> @@ -72,7 +73,7 @@ public class AppClientXml extends CommonXml {
>      private final ExtensionXml extensionXml;
>  
>      public AppClientXml(final ModuleLoader loader, final ExtensionRegistry extensionRegistry) {
> -        super();
> +        super(new AppClientSocketBindingsXml());
>          extensionXml = new ExtensionXml(loader, null, extensionRegistry);
>      }
>  
> @@ -410,4 +411,12 @@ public class AppClientXml extends CommonXml {
>              throws XMLStreamException {
>          // we don't marshall appclient.xml
>      }
> +
> +    static class AppClientSocketBindingsXml extends SocketBindingsXml {
> +        @Override
> +        protected void writeExtraAttributes(XMLExtendedStreamWriter writer, ModelNode bindingGroup) throws XMLStreamException {
> +            SocketBindingGroupResourceDefinition.PORT_OFFSET.marshallAsAttribute(bindingGroup, writer);
> +        }
> +    }
> +
>  }
> {code}
> Full diff at https://github.com/wildfly/wildfly/commit/2dd7eb1a3885d6496762ed399745fb14923d8879 (if github keeps these when I change my branch)
> Another thing is that AutoIgnoredResourcesDomainTestCase should be removed. It now lives in core following the work on WFCORE-401.



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

From issues at jboss.org  Wed Dec  6 11:20:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4710) Upgrade to Beanutils 1.9.2
In-Reply-To: <JIRA.12573415.1433161625000@Atlassian.JIRA>
References: <JIRA.12573415.1433161625000@Atlassian.JIRA>
	<JIRA.12573415.1433161625000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573415.1433161625000.87631.1512577230482@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4710.
----------------------------


> Upgrade to Beanutils 1.9.2
> --------------------------
>
>                 Key: WFLY-4710
>                 URL: https://issues.jboss.org/browse/WFLY-4710
>             Project: WildFly
>          Issue Type: Component Upgrade
>    Affects Versions: 10.0.0.Alpha2
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha4
>
>
> Apache ActiveMQ Artemis depends on Beanutils 1.9.2 and its BeanIntrospector



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

From issues at jboss.org  Wed Dec  6 11:20:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4973) Intermittent failures in
 client side tests that use remote EJB
In-Reply-To: <JIRA.12578701.1437470027000@Atlassian.JIRA>
References: <JIRA.12578701.1437470027000@Atlassian.JIRA>
	<JIRA.12578701.1437470027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578701.1437470027000.87635.1512577230739@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4973.
----------------------------


> Intermittent failures in client side tests that use remote EJB
> --------------------------------------------------------------
>
>                 Key: WFLY-4973
>                 URL: https://issues.jboss.org/browse/WFLY-4973
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.Alpha6
>
>
> There are lots of intermittent failures in tests that use remote EJB, and they all fail with the same failure message (EJBCLIENT000025: No EJB receiver available for handling...).
> An example of this is here: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=61476&buildTypeId=WFPR
> The issue is that there is no guard to make sure that the 'module availability' message for the deployment has been processed before the test starts (there is a guard for this on initial connection, with a hard coded 5 second timeout, however the test suite will re-use connections between tests).
> At the moment I don't really have any idea of a good way to fix this. 
> This failure does not affect end user code because user code does usually perform a deployment then make a call (although it could affect end user Arquillian tests).
> This issue can be reproduced 100% of the time by adding a sleep into org.jboss.ejb.client.remoting.ModuleAvailabilityMessageHandler#processMessage, then running the test suite. The first test that uses the remote EJB will pass (because the client waits for the initial module availability message), but all subsequent tests that attempt to use it will fail.



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

From issues at jboss.org  Wed Dec  6 11:20:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4583) Do not log messages about
 XAResources which implement XAResourceWrapper SPI and that are known to
 have completed safely
In-Reply-To: <JIRA.12570682.1430813690000@Atlassian.JIRA>
References: <JIRA.12570682.1430813690000@Atlassian.JIRA>
	<JIRA.12570682.1430813690000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570682.1430813690000.87641.1512577231054@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4583.
----------------------------


> Do not log messages about XAResources which implement XAResourceWrapper SPI and that are known to have completed safely
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4583
>                 URL: https://issues.jboss.org/browse/WFLY-4583
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Gytis Trikleris
>             Fix For: 10.0.0.Alpha1
>
>
> n the XA protocol a time window exists wherein the RM has committed and thus forgotten a tx branch but the TM has not yet deleted its log. A crash during this window currently results in an unrecoverable situation, as the TM assumes the branch belongs to an RM that is uncontactable and will retry recovery indefinitely. This stems from an inability to relate the Xid to a specific RM. It can be overridden globally with JTAEnvironmentBean.xaAssumeRecoveryComplete, but we would prefer more fine-grained control. With the availability of RM id information from XAResourceWrapper this becomes feasible.



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

From issues at jboss.org  Wed Dec  6 11:20:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4612)
 EjbJndiBindingsDeploymentUnitProcessor logs non-i18n message at INFO
In-Reply-To: <JIRA.12571069.1431025468000@Atlassian.JIRA>
References: <JIRA.12571069.1431025468000@Atlassian.JIRA>
	<JIRA.12571069.1431025468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571069.1431025468000.87645.1512577231134@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4612.
----------------------------


> EjbJndiBindingsDeploymentUnitProcessor logs non-i18n message at INFO
> --------------------------------------------------------------------
>
>                 Key: WFLY-4612
>                 URL: https://issues.jboss.org/browse/WFLY-4612
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Bartosz Baranowski
>             Fix For: 10.0.0.Alpha4
>
>
> ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EjbJndiBindingsDeploymentUnitProcessor.java
> {code}
> jndiBindingsLogMessage.append("JNDI bindings for session bean named " + sessionBean.getEJBName() + " in deployment unit " + deploymentUnit + " are as follows:\n\n");
> {code}
> That eventually gets logged at INFO.



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

From issues at jboss.org  Wed Dec  6 11:20:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4848) Ignore failing legacy
 messaging transformer tests
In-Reply-To: <JIRA.12576675.1435697208000@Atlassian.JIRA>
References: <JIRA.12576675.1435697208000@Atlassian.JIRA>
	<JIRA.12576675.1435697208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576675.1435697208000.87650.1512577231384@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4848.
----------------------------


> Ignore failing legacy messaging transformer tests
> -------------------------------------------------
>
>                 Key: WFLY-4848
>                 URL: https://issues.jboss.org/browse/WFLY-4848
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 10.0.0.Alpha5
>
>
> When running {{legacy/messages}} subsystem tests with {{-Djboss.test.transformers.eap}} fail. Two fail with a {{ClassNotFoundException}} and two fail assertions. See http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=58617&buildTypeId=WF_MasterLinux&tab=buildResultsDiv for details.
> For now I'll {{@Ignore}} the tests.



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

From issues at jboss.org  Wed Dec  6 11:20:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5118) Change WebMigrateOperation to
 use ModelDescriptionConstants instead of KeyStoreAttributes
In-Reply-To: <JIRA.12581636.1439850361000@Atlassian.JIRA>
References: <JIRA.12581636.1439850361000@Atlassian.JIRA>
	<JIRA.12581636.1439850361000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581636.1439850361000.87653.1512577231595@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5118.
----------------------------


> Change WebMigrateOperation to use ModelDescriptionConstants instead of KeyStoreAttributes
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5118
>                 URL: https://issues.jboss.org/browse/WFLY-5118
>             Project: WildFly
>          Issue Type: Task
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>
> And remove the domain-management dependency



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

From issues at jboss.org  Wed Dec  6 11:20:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5058) Upgrade Narayana to
	5.2.1.Final
In-Reply-To: <JIRA.12580341.1438767076000@Atlassian.JIRA>
References: <JIRA.12580341.1438767076000@Atlassian.JIRA>
	<JIRA.12580341.1438767076000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580341.1438767076000.87658.1512577231799@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5058.
----------------------------


> Upgrade Narayana to 5.2.1.Final
> -------------------------------
>
>                 Key: WFLY-5058
>                 URL: https://issues.jboss.org/browse/WFLY-5058
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 10.0.0.Beta1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:32 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5123) Execution error:
 org.infinispan.util.concurrent.TimeoutException: Timed out waiting for
 topology
In-Reply-To: <JIRA.12581656.1439886483000@Atlassian.JIRA>
References: <JIRA.12581656.1439886483000@Atlassian.JIRA>
	<JIRA.12581656.1439886483000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581656.1439886483000.87665.1512577232247@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5123.
----------------------------


> Execution error: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5123
>                 URL: https://issues.jboss.org/browse/WFLY-5123
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>
> Seen regularly in basically every failover test (no matter what failover type/cache used). 
> Setup: 4 node cluster, one node at time is shutdown, while standalone clients keep calling the application.
> After failing one node(failover type: jvmkill/shutdown/undeploy) - perf20 in this case, perf21 logged the following error message:
> {code}
> [JBossINF] [0m[31m12:57:35,029 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (transport-thread--p7-t10) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 20
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferLockImpl.waitForTransactionData(StateTransferLockImpl.java:92)
> [JBossINF] 	at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTransactionData(BaseStateTransferInterceptor.java:96)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:274)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:243)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:119)
> [JBossINF] 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> [JBossINF] 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> [JBossINF] 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> [JBossINF] 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> [JBossINF] 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> [JBossINF] 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1613)
> [JBossINF] 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> [JBossINF] 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> [JBossINF] 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> [JBossINF] 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> [JBossINF] 	at org.wildfly.clustering.server.registry.CacheRegistry.topologyChanged(CacheRegistry.java:152)
> [JBossINF] 	at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
> [JBossINF] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] 	at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> [JBossINF] 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> [JBossINF] 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> [JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> [JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1170)
> [JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1135)
> [JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyTopologyChanged(CacheNotifierImpl.java:590)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:203)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:47)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:115)
> [JBossINF] 	at org.infinispan.topology.LocalTopologyManagerImpl.doHandleTopologyUpdate(LocalTopologyManagerImpl.java:282)
> [JBossINF] 	at org.infinispan.topology.LocalTopologyManagerImpl$1.run(LocalTopologyManagerImpl.java:217)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.runInternal(SemaphoreCompletionService.java:173)
> [JBossINF] 	at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.run(SemaphoreCompletionService.java:151)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> [JBossINF] 
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-shutdown-dist-async/3/console-perf21/
> This error sometimes occur just before the server shuts down, as can be seen here:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-shutdown-dist-async/3/console-perf19/
> See also: [JBEAP-505#comment-13098103|https://issues.jboss.org/browse/JBEAP-505?focusedCommentId=13098103&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13098103]
> This issue is also related to: [WFLY-4697#comment-13083024|https://issues.jboss.org/browse/WFLY-4697?focusedCommentId=13083024&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13083024]



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

From issues at jboss.org  Wed Dec  6 11:20:32 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5211) Upgrade to JBoss Negotiation
	2.3.8.Final
In-Reply-To: <JIRA.12582674.1440594500000@Atlassian.JIRA>
References: <JIRA.12582674.1440594500000@Atlassian.JIRA>
	<JIRA.12582674.1440594500000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582674.1440594500000.87672.1512577232511@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5211.
----------------------------


> Upgrade to JBoss Negotiation 2.3.8.Final
> ----------------------------------------
>
>                 Key: WFLY-5211
>                 URL: https://issues.jboss.org/browse/WFLY-5211
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:32 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4883) Remove the redundant
 -core.xml definitions from the WildFly Feature Pack
In-Reply-To: <JIRA.12577249.1436280237000@Atlassian.JIRA>
References: <JIRA.12577249.1436280237000@Atlassian.JIRA>
	<JIRA.12577249.1436280237000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577249.1436280237000.87675.1512577232644@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4883.
----------------------------


> Remove the redundant -core.xml definitions from the WildFly Feature Pack
> ------------------------------------------------------------------------
>
>                 Key: WFLY-4883
>                 URL: https://issues.jboss.org/browse/WFLY-4883
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 10.0.0.Alpha5
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:32 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4758) Upgrade to WF core
	2.0.0.Alpha4
In-Reply-To: <JIRA.12574242.1433782616000@Atlassian.JIRA>
References: <JIRA.12574242.1433782616000@Atlassian.JIRA>
	<JIRA.12574242.1433782616000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574242.1433782616000.87678.1512577232816@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4758.
----------------------------


> Upgrade to WF core 2.0.0.Alpha4
> -------------------------------
>
>                 Key: WFLY-4758
>                 URL: https://issues.jboss.org/browse/WFLY-4758
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 10.0.0.Alpha3
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5187) Standalone client fails to
 connect through remote connection factory over ipv6
In-Reply-To: <JIRA.12582345.1440425085000@Atlassian.JIRA>
References: <JIRA.12582345.1440425085000@Atlassian.JIRA>
	<JIRA.12582345.1440425085000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582345.1440425085000.87684.1512577233192@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5187.
----------------------------


> Standalone client fails to connect through remote connection factory over ipv6
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-5187
>                 URL: https://issues.jboss.org/browse/WFLY-5187
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Martin ?vehla
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When a standalone client connects to EAP over ipv6 and tries to do lookup on for RemoteConnectionFactory (as defined in the default standalone-full and standalone-full-ha configuration), the lookup fails with following error:
> Caused by: java.io.InvalidObjectException: URLDecoder: Illegal hex characters in escape (%) pattern - For input string: "et"
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:117)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1308)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:149)
> at org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:59)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:232)
> 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.marshalling.TraceInformation: null
> You can reproduce the issue by running org.jboss.as.test.smoke.messaging.client.jms.JmsClientTestCase.testSendAndReceive from upstream testsuite.



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


From issues at jboss.org  Wed Dec  6 11:20:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5031) Upgrade wildfly-arquillian
 from 1.0.0.Final to 1.0.1.Final
In-Reply-To: <JIRA.12579810.1438193013000@Atlassian.JIRA>
References: <JIRA.12579810.1438193013000@Atlassian.JIRA>
	<JIRA.12579810.1438193013000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579810.1438193013000.87687.1512577233423@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5031.
----------------------------


> Upgrade wildfly-arquillian from 1.0.0.Final to 1.0.1.Final
> ----------------------------------------------------------
>
>                 Key: WFLY-5031
>                 URL: https://issues.jboss.org/browse/WFLY-5031
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Test Suite
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 10.0.0.Beta1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5184) Read-attribute on an EJB
 timer fails if there are no more timeouts
In-Reply-To: <JIRA.12582321.1440419049000@Atlassian.JIRA>
References: <JIRA.12582321.1440419049000@Atlassian.JIRA>
	<JIRA.12582321.1440419049000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582321.1440419049000.87690.1512577233516@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5184.
----------------------------


> Read-attribute on an EJB timer fails if there are no more timeouts
> ------------------------------------------------------------------
>
>                 Key: WFLY-5184
>                 URL: https://issues.jboss.org/browse/WFLY-5184
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 10.0.0.CR1
>
>
> When a read-attribute operation is invoked on an EJB timer that has no timeouts remaining, the operation fails without returning any useful information to the client:
> {noformat}
>  {
>     "outcome" : "failed",
>     "rolled-back" : true
> }
> {noformat}
> It is because a NoMoreTimeoutException is thrown from the TimerServiceImpl and this exception is not handled by the read-attribute handler. This occurs in the server log:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
>     ("deployment" => "ejb-mgmt-timers.jar"),
>     ("subsystem" => "ejb3"),
>     ("stateless-session-bean" => "TimerBean"),
>     ("service" => "timer-service"),
>     ("timer" => "9a93b559-3526-4b72-95e7-760c5bc50484")
> ]): javax.ejb.NoMoreTimeoutsException: WFLYEJB0328: No more timeouts for timer [id=9a93b559-3526-4b72-95e7-760c5bc50484 timedObjectId=ejb-mgmt-timers.ejb-mgmt-timers.TimerBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl at 72e447ae initialExpiration=Mon Aug 24 13:38:37 CEST 2015 intervalDuration(in milli sec)=0 nextExpiration=null timerState=IN_TIMEOUT info=PersistentIntervalTimerCLITestCase]
>         at org.jboss.as.ejb3.timerservice.TimerImpl.getNextTimeout(TimerImpl.java:256)
>         at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$6.readAttribute(TimerResourceDefinition.java:240)
>         at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractReadAttributeHandler.executeRuntime(TimerResourceDefinition.java:376)
>         at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractTimerHandler$1.execute(TimerResourceDefinition.java:340)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:846)
>         at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:637)
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
>         at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1272)
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:394)
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:225)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147)
>         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:147)
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298)
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
>         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)
> {noformat}
> I think the read-attribute handler should rather catch this exception, log it, and leave the next-timeout and time-remaining attributes undefined in this case.



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

From issues at jboss.org  Wed Dec  6 11:20:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5282) [Migration operation] [Web to
 Undertow] Connector attribute redirect-port is not migrated
In-Reply-To: <JIRA.12584019.1441373460000@Atlassian.JIRA>
References: <JIRA.12584019.1441373460000@Atlassian.JIRA>
	<JIRA.12584019.1441373460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584019.1441373460000.87694.1512577233778@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5282.
----------------------------


> [Migration operation] [Web to Undertow] Connector attribute redirect-port is not migrated
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5282
>                 URL: https://issues.jboss.org/browse/WFLY-5282
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> Connector attribute {{redirect-port}} is not migrated. The {{redirect-port}} behaves the same as {{redirect-binding}} with exception of directly defining port to use. Thus it could be migrated to {{redirect-socket}} attribute in Undertow (with some logic for defining/obtaining appropriate socket binding) or there should be at least printed suitable warning preventing to migrate such attribute.



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

From issues at jboss.org  Wed Dec  6 11:20:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4589)
 java.lang.IllegalStateException: PBOX000048: Failed to obtain
 ApplicationPolicy for domain other
In-Reply-To: <JIRA.12570733.1430830367000@Atlassian.JIRA>
References: <JIRA.12570733.1430830367000@Atlassian.JIRA>
	<JIRA.12570733.1430830367000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570733.1430830367000.87699.1512577234015@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4589.
----------------------------


> java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4589
>                 URL: https://issues.jboss.org/browse/WFLY-4589
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.0.CR1
>         Environment: java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
> cheffamille:wildfly-9.0.0.CR1 jfarcand$
>            Reporter: Jeanfrancois Arcand
>            Assignee: Stuart Douglas
>            Priority: Minor
>             Fix For: 10.0.0.Beta1
>
>
> Deploy atmosphere-chat.war (download it from Maven). Deploy, use WebSockets, then shutdown Wildfly 9.0.0.CR1
> 08:47:41,792 ERROR [io.undertow.websockets.jsr.request] (default task-17) UT026006: Exception running web socket method: java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
> 	at org.jboss.security.plugins.mapping.JBossMappingManager.getMappingContext(JBossMappingManager.java:67)
> 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.setup(SecurityContextThreadSetupAction.java:110)
> 	at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42)
> 	at io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod(ServerWebSocketContainer.java:416)
> 	at io.undertow.websockets.jsr.ServerWebSocketContainer$3.run(ServerWebSocketContainer.java:403)
> 	at io.undertow.websockets.jsr.OrderedExecutor$ExecutorTask.run(OrderedExecutor.java:67)
> 	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 Dec  6 11:20:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5188) DistributedWorkManager needs
 to handle unknown fork responses.
In-Reply-To: <JIRA.12582356.1440427799000@Atlassian.JIRA>
References: <JIRA.12582356.1440427799000@Atlassian.JIRA>
	<JIRA.12582356.1440427799000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582356.1440427799000.87704.1512577234283@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5188.
----------------------------


> DistributedWorkManager needs to handle unknown fork responses.
> --------------------------------------------------------------
>
>                 Key: WFLY-5188
>                 URL: https://issues.jboss.org/browse/WFLY-5188
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JCA
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>
> The JGroupsTransport employed by the DistributedWorkManager uses synchronous multicasting via the RpcDispatcher.  Since the JCA default configuration was modified to use fork channels, we need to ensure that it handles an exception case specific for fork channels, i.e. the case where a message is received by a node on which no such DWM exists.
> As I see it, there are 2 ways we can fix this:
> # Configure the RpcDispatcher with a custom response marshaller capable of recognizing unknown fork responses
> # Implement a transport that leverages CommandDispatcher, which already handles this exception case.
> #1 is the easiest.  The only hiccup is that the RpcDispatcher field in JGroupsTransport is private, which requires reflection to access from a subclass.
> #2 is probably the ideal long term solution.  The DistributedWorkManager already employs a command pattern, so using CommandDispatcher is a natural fit.  Using the CommandDispatcher will also simplifies marshalling/unmarshalling of the transport parameters.  Additionally, using the public clustering API allows us to remove the direct dependency on org.jgroups module from the connector subsystems.  The only hiccup here is that in order to optimize the marshalling of the command objects, requires the use of the marshalling API introduced as part of WFLY-5091, which, at the time of this writing, has not yet been merged into WF master.
> Given the above, I suggest a 2 phase solution, where we implement #1 for now, and #2 when the missing pieces are in place.



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

From issues at jboss.org  Wed Dec  6 11:20:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5190) Upgrade JGroups to 3.6.5.Final
In-Reply-To: <JIRA.12582362.1440429501000@Atlassian.JIRA>
References: <JIRA.12582362.1440429501000@Atlassian.JIRA>
	<JIRA.12582362.1440429501000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582362.1440429501000.87709.1512577234478@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5190.
----------------------------


> Upgrade JGroups to 3.6.5.Final
> ------------------------------
>
>                 Key: WFLY-5190
>                 URL: https://issues.jboss.org/browse/WFLY-5190
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4723) Make jgroups protocols
 support indexed adds
In-Reply-To: <JIRA.12573536.1433245200000@Atlassian.JIRA>
References: <JIRA.12573536.1433245200000@Atlassian.JIRA>
	<JIRA.12573536.1433245200000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573536.1433245200000.87715.1512577234694@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4723.
----------------------------


> Make jgroups protocols support indexed adds
> -------------------------------------------
>
>                 Key: WFLY-4723
>                 URL: https://issues.jboss.org/browse/WFLY-4723
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 10.0.0.Alpha3
>
>
> With the work done on WFCORE-401 it is important that if a protocol is added to a master that it appears in the correct location on the slave when the slave reconnects. This is made possible by the indexed adds introduced by WFCORE-598. If not set up as ordered children, a new protocol added to the middle of a stack would appear at the end, which is not what we want



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

From issues at jboss.org  Wed Dec  6 11:20:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4909) Upgrade HAL to 2.8.2
In-Reply-To: <JIRA.12577771.1436771024000@Atlassian.JIRA>
References: <JIRA.12577771.1436771024000@Atlassian.JIRA>
	<JIRA.12577771.1436771024000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577771.1436771024000.87718.1512577234788@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4909.
----------------------------


> Upgrade HAL to 2.8.2
> --------------------
>
>                 Key: WFLY-4909
>                 URL: https://issues.jboss.org/browse/WFLY-4909
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.Alpha6
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4598) Remove class name string from
 RTS subsystem
In-Reply-To: <JIRA.12570911.1430925816000@Atlassian.JIRA>
References: <JIRA.12570911.1430925816000@Atlassian.JIRA>
	<JIRA.12570911.1430925816000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570911.1430925816000.87723.1512577235093@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4598.
----------------------------


> Remove class name string from RTS subsystem
> -------------------------------------------
>
>                 Key: WFLY-4598
>                 URL: https://issues.jboss.org/browse/WFLY-4598
>             Project: WildFly
>          Issue Type: Task
>          Components: Transactions
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 10.0.0.Alpha1
>
>
> Replace hard coded class name string with Class.getName()



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

From issues at jboss.org  Wed Dec  6 11:20:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4198) NullPointerException in
 LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
In-Reply-To: <JIRA.12559988.1419265827000@Atlassian.JIRA>
References: <JIRA.12559988.1419265827000@Atlassian.JIRA>
	<JIRA.12559988.1419265827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559988.1419265827000.87728.1512577235357@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4198.
----------------------------


> NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4198
>                 URL: https://issues.jboss.org/browse/WFLY-4198
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.0.Final
>            Reporter: Sergiy Barlabanov
>            Assignee: Bartosz Baranowski
>             Fix For: 10.0.0.Alpha6
>
>         Attachments: patch.diff
>
>
> When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below).
> The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap.
> So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null.
> Currently there is no workaround for that :(.
> {noformat}
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
> 	at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
> 	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:744)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:20:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4623) Upgrade WildFly Arquillian
 from 1.0.0.Alpha5 to 1.0.0.CR1
In-Reply-To: <JIRA.12571327.1431364270000@Atlassian.JIRA>
References: <JIRA.12571327.1431364270000@Atlassian.JIRA>
	<JIRA.12571327.1431364270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571327.1431364270000.87731.1512577235504@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4623.
----------------------------


> Upgrade WildFly Arquillian from 1.0.0.Alpha5 to 1.0.0.CR1
> ---------------------------------------------------------
>
>                 Key: WFLY-4623
>                 URL: https://issues.jboss.org/browse/WFLY-4623
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Test Suite
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4729) shared-session-config_1_0.xsd
 description of <cache-name> is wrong
In-Reply-To: <JIRA.12573674.1433314794000@Atlassian.JIRA>
References: <JIRA.12573674.1433314794000@Atlassian.JIRA>
	<JIRA.12573674.1433314794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573674.1433314794000.87736.1512577235695@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4729.
----------------------------


> shared-session-config_1_0.xsd description of <cache-name> is wrong
> ------------------------------------------------------------------
>
>                 Key: WFLY-4729
>                 URL: https://issues.jboss.org/browse/WFLY-4729
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Alpha2
>            Reporter: Ladislav Thon
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> As described in JBMETA-387, the {{<cache-name>}} documentation in the XSD refers to AS6 syntax. As of AS7, cache container and cache are delimited by a ".", not a "/".



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

From issues at jboss.org  Wed Dec  6 11:20:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4644) enabling access-log for
 virtual server is not effective before server reload but CLI does not
 require that
In-Reply-To: <JIRA.12571978.1431961718000@Atlassian.JIRA>
References: <JIRA.12571978.1431961718000@Atlassian.JIRA>
	<JIRA.12571978.1431961718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571978.1431961718000.87741.1512577235839@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4644.
----------------------------


> enabling access-log for virtual server is not effective before server reload but CLI does not require that
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4644
>                 URL: https://issues.jboss.org/browse/WFLY-4644
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.0.CR1
>            Reporter: Jan Stourac
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha3
>
>
> When access-log is enabled for virtual host via CLI it does not want to perform server reload. But until server reload is executed logging is not enabled. When server reload is performed then logging works OK.



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

From issues at jboss.org  Wed Dec  6 11:20:36 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4675) Wrong help message in
	wsconsume.bat
In-Reply-To: <JIRA.12572640.1432628164000@Atlassian.JIRA>
References: <JIRA.12572640.1432628164000@Atlassian.JIRA>
	<JIRA.12572640.1432628164000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572640.1432628164000.87746.1512577236052@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4675.
----------------------------


> Wrong help message in wsconsume.bat
> -----------------------------------
>
>                 Key: WFLY-4675
>                 URL: https://issues.jboss.org/browse/WFLY-4675
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>            Priority: Minor
>             Fix For: 10.0.0.Alpha5
>
>
> Description of problem:
>    Help message in wsconsume.bat contains wrong "usage" section.
> How reproducible:
>    Always on Windows
> Steps to Reproduce:
>    1. wsconsume.bat -h
> Actual results:
>    ...
>    usage: org.jboss.ws.tools.cmd.WSConsume [options] <wsdl-url>
>    ... 
> Expected results on Windows:
>    ...
>    usage: wsconsume.bat [options] <wsdl-url>
>    ... 
> Additional info:
>    On linux:
>       ./wsconsume.sh -h
>           ... 
> 	  usage: wsconsume.sh [options] <wsdl-url>
> 	  ...



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


From issues at jboss.org  Wed Dec  6 11:20:36 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3642) Make length of session id
	configurable
In-Reply-To: <JIRA.12546832.1405676896000@Atlassian.JIRA>
References: <JIRA.12546832.1405676896000@Atlassian.JIRA>
	<JIRA.12546832.1405676896000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546832.1405676896000.87752.1512577236368@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3642.
----------------------------


> Make length of session id configurable
> --------------------------------------
>
>                 Key: WFLY-3642
>                 URL: https://issues.jboss.org/browse/WFLY-3642
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final, 8.2.0.Final
>         Environment: any
>            Reporter: Jan Dittberner
>            Assignee: Stuart Douglas
>            Priority: Minor
>             Fix For: 10.0.0.Beta2
>
>
> At the moment the session ids generated by WildFly/Undertow are of a fixed length of 18 characters. The used [SecureRandomSessionIdGenerator|https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/session/SecureRandomSessionIdGenerator.java] allows for setting a custom length but this capability is not used in WildFly yet.
> It would be nice to have this capability in the [web subsystem configuration|https://docs.jboss.org/author/display/WFLY8/Undertow+(web)+subsystem+configuration].



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

From issues at jboss.org  Wed Dec  6 11:20:36 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3769) Implement graceful shutdown
 for batch tasks
In-Reply-To: <JIRA.12550189.1409027548000@Atlassian.JIRA>
References: <JIRA.12550189.1409027548000@Atlassian.JIRA>
	<JIRA.12550189.1409027548000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12550189.1409027548000.87756.1512577236621@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3769.
----------------------------


> Implement graceful shutdown for batch tasks
> -------------------------------------------
>
>                 Key: WFLY-3769
>                 URL: https://issues.jboss.org/browse/WFLY-3769
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Batch
>            Reporter: Stuart Douglas
>            Assignee: James Perkins
>             Fix For: 10.0.0.Alpha4
>
>
> This should make sure that all batch jobs have completed before the container shuts down, and not allow new jobs to start while the container is suspended. 



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

From issues at jboss.org  Wed Dec  6 11:20:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5340) Unable to specify module when
 specifying custom JACC policy class.
In-Reply-To: <JIRA.12584861.1442249900000@Atlassian.JIRA>
References: <JIRA.12584861.1442249900000@Atlassian.JIRA>
	<JIRA.12584861.1442249900000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584861.1442249900000.87764.1512577237064@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5340.
----------------------------


> Unable to specify module when specifying custom JACC policy class.
> ------------------------------------------------------------------
>
>                 Key: WFLY-5340
>                 URL: https://issues.jboss.org/browse/WFLY-5340
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.CR1
>
>
> It is currently possible to specify the 'javax.security.jacc.policy.provider' system property, however it is not possible to specify a module.
> From the JACC specification: -
> _For each JRE of a J2EE 1.4 or later version Java EE application server, if the 
> system property 
> ?javax.security.jacc.policy.provider
> ? is defined, 
> the application server must construct an 
> instance of the class identified by the 
> system property, confirm that the 
> resulting object is an instance of 
> java.security.Policy, 
> and set, by calling the 
> java.security.Policy.setPolicy
>  method, the resulting object as the 
> corresponding Policy object u
> sed by the JRE. _
> The specification only specifies that the system property identifies the class, it does not specify how.  
> In it's simplest form we should assume this is just a class name, in a more complex form we should allow the module to be specified.



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


From issues at jboss.org  Wed Dec  6 11:20:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2833) data-source:enalbe and
 datasource:write-attribute(name=enabled, value=true) should have same result
In-Reply-To: <JIRA.12530655.1391011485000@Atlassian.JIRA>
References: <JIRA.12530655.1391011485000@Atlassian.JIRA>
	<JIRA.12530655.1391011485000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530655.1391011485000.87771.1512577237401@Atlassian.JIRA>


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

Kabir Khan closed WFLY-2833.
----------------------------


> data-source:enalbe and datasource:write-attribute(name=enabled, value=true) should have same result
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2833
>                 URL: https://issues.jboss.org/browse/WFLY-2833
>             Project: WildFly
>          Issue Type: Task
>          Components: JCA
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Beta1
>
>
> Currently enabled attribute always require a reload, while it should provide same functionalyity of :enable (and symmetric :disable operation) enabling/disabling datasource runtime.



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

From issues at jboss.org  Wed Dec  6 11:20:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5347) Upgrade HAL to 2.8.10.Final
In-Reply-To: <JIRA.12584974.1442328369000@Atlassian.JIRA>
References: <JIRA.12584974.1442328369000@Atlassian.JIRA>
	<JIRA.12584974.1442328369000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584974.1442328369000.87774.1512577237601@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5347.
----------------------------


> Upgrade HAL to 2.8.10.Final
> ---------------------------
>
>                 Key: WFLY-5347
>                 URL: https://issues.jboss.org/browse/WFLY-5347
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.CR1
>
>
> New homepage and bugfixes



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

From issues at jboss.org  Wed Dec  6 11:20:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3334) Event with qualifier
 @Initialized not raised if no webapp is deployed
In-Reply-To: <JIRA.12533335.1393414183000@Atlassian.JIRA>
References: <JIRA.12533335.1393414183000@Atlassian.JIRA>
	<JIRA.12533335.1393414183000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533335.1393414183000.87780.1512577237869@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3334.
----------------------------


> Event with qualifier @Initialized not raised if no webapp is deployed
> ---------------------------------------------------------------------
>
>                 Key: WFLY-3334
>                 URL: https://issues.jboss.org/browse/WFLY-3334
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.1.0.CR1
>         Environment: Wildfly 8.0.0.Final, OpenJDK 1.7.0_45
>            Reporter: Daniel Lechner
>            Assignee: Jozef Hartinger
>             Fix For: 10.0.0.Alpha5
>
>
> As stated in the CDI-specification (section 6.7.3. Application context lifecycle)
> {quote}
> An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired when the application is destroyed. 
> {quote}
> But in my environment this is only true, if the deployed application (packaged in an EAR) contains a webapplication (as WAR inside the EAR). If there is no webapplication, the event is not raised and observer-methods are not called at all.



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

From issues at jboss.org  Wed Dec  6 11:20:38 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4560) Upgrade Narayana to version
	5.1.1.Final
In-Reply-To: <JIRA.12569867.1430143405000@Atlassian.JIRA>
References: <JIRA.12569867.1430143405000@Atlassian.JIRA>
	<JIRA.12569867.1430143405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569867.1430143405000.87785.1512577238060@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4560.
----------------------------


> Upgrade Narayana to version 5.1.1.Final
> ---------------------------------------
>
>                 Key: WFLY-4560
>                 URL: https://issues.jboss.org/browse/WFLY-4560
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 10.0.0.Alpha1
>
>
> Latest release of Narayana is available now.



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

From issues at jboss.org  Wed Dec  6 11:20:38 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5341) Example subsystem config is
 missing security manager subsystem
In-Reply-To: <JIRA.12584902.1442296753000@Atlassian.JIRA>
References: <JIRA.12584902.1442296753000@Atlassian.JIRA>
	<JIRA.12584902.1442296753000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584902.1442296753000.87788.1512577238117@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5341.
----------------------------


> Example subsystem config is missing security manager subsystem
> --------------------------------------------------------------
>
>                 Key: WFLY-5341
>                 URL: https://issues.jboss.org/browse/WFLY-5341
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:38 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5264) Upgrade JBeret to 1.2.0.Final
In-Reply-To: <JIRA.12583599.1441207301000@Atlassian.JIRA>
References: <JIRA.12583599.1441207301000@Atlassian.JIRA>
	<JIRA.12583599.1441207301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583599.1441207301000.87792.1512577238286@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5264.
----------------------------


> Upgrade JBeret to 1.2.0.Final
> -----------------------------
>
>                 Key: WFLY-5264
>                 URL: https://issues.jboss.org/browse/WFLY-5264
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Batch
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Blocker
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:38 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3918) Cannot disable
	ConsoleRedirectService
In-Reply-To: <JIRA.12553773.1412095631000@Atlassian.JIRA>
References: <JIRA.12553773.1412095631000@Atlassian.JIRA>
	<JIRA.12553773.1412095631000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553773.1412095631000.87798.1512577238572@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3918.
----------------------------


> Cannot disable ConsoleRedirectService
> -------------------------------------
>
>                 Key: WFLY-3918
>                 URL: https://issues.jboss.org/browse/WFLY-3918
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final
>            Reporter: Graham Johnson
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Alpha6
>
>
> Wildfly Undertow (via org.wildfly.extension.undertow.HostAdd and org.wildfly.extension.undertow.ConsoleRedirectService) redirects all /console/... URL requests (on port 8080/8443) to /console on port 9990.  
> This prevents developing or porting applications that themselves need to serve /console/... URLs.
> There needs to be a way to disable (in the undertow subsystem configuration) the adding of ConsoleRedirectService by HostAdd.



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

From issues at jboss.org  Wed Dec  6 11:20:38 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5191) IronJacamar 1.2.6.Final
In-Reply-To: <JIRA.12582364.1440429630000@Atlassian.JIRA>
References: <JIRA.12582364.1440429630000@Atlassian.JIRA>
	<JIRA.12582364.1440429630000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582364.1440429630000.87801.1512577238721@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5191.
----------------------------


> IronJacamar 1.2.6.Final
> -----------------------
>
>                 Key: WFLY-5191
>                 URL: https://issues.jboss.org/browse/WFLY-5191
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:38 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5054) RemotingProfileRemove needs
 to extend AbstractRemoveStepHandler not ServiceRemoveStepHandler
In-Reply-To: <JIRA.12580292.1438706496000@Atlassian.JIRA>
References: <JIRA.12580292.1438706496000@Atlassian.JIRA>
	<JIRA.12580292.1438706496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580292.1438706496000.87804.1512577238985@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5054.
----------------------------


> RemotingProfileRemove needs to extend AbstractRemoveStepHandler not ServiceRemoveStepHandler
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5054
>                 URL: https://issues.jboss.org/browse/WFLY-5054
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 10.0.0.Beta1
>
>
> For some reason the class extends ServiceRemoveStepHandler but then replaces all of the functionality from that class.



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

From issues at jboss.org  Wed Dec  6 11:20:39 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:39 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5329) Add support for an automatic
 configured strict-max-pool and make it the default for SLSB and MDBs
In-Reply-To: <JIRA.12584739.1442008263000@Atlassian.JIRA>
References: <JIRA.12584739.1442008263000@Atlassian.JIRA>
	<JIRA.12584739.1442008263000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584739.1442008263000.87807.1512577239037@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5329.
----------------------------


> Add support for an automatic configured strict-max-pool and make it the default for SLSB and MDBs
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5329
>                 URL: https://issues.jboss.org/browse/WFLY-5329
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Jason Greene
>            Assignee: Jason Greene
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:39 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:39 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4739) Add option to disable
 websockets on a per deployment basis
In-Reply-To: <JIRA.12573837.1433406395000@Atlassian.JIRA>
References: <JIRA.12573837.1433406395000@Atlassian.JIRA>
	<JIRA.12573837.1433406395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573837.1433406395000.87811.1512577239218@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4739.
----------------------------


> Add option to disable websockets on a per deployment basis
> ----------------------------------------------------------
>
>                 Key: WFLY-4739
>                 URL: https://issues.jboss.org/browse/WFLY-4739
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha4
>
>
> This will use the existing jboss-web.xml flag



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

From issues at jboss.org  Wed Dec  6 11:20:39 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:39 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4819) Upgrade Apache CXF from 3.0.5
	to 3.1.2
In-Reply-To: <JIRA.12575954.1435050154000@Atlassian.JIRA>
References: <JIRA.12575954.1435050154000@Atlassian.JIRA>
	<JIRA.12575954.1435050154000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575954.1435050154000.87816.1512577239448@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4819.
----------------------------


> Upgrade Apache CXF from 3.0.5 to 3.1.2
> --------------------------------------
>
>                 Key: WFLY-4819
>                 URL: https://issues.jboss.org/browse/WFLY-4819
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Tomas Hofman
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Beta1
>
>
> Upgrade to Apache CXF 3.1.2 when available.



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

From issues at jboss.org  Wed Dec  6 11:20:39 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:39 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4585) Provide JMS forward
	compatibility
In-Reply-To: <JIRA.12570689.1430816022000@Atlassian.JIRA>
References: <JIRA.12570689.1430816022000@Atlassian.JIRA>
	<JIRA.12570689.1430816022000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570689.1430816022000.87821.1512577239670@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4585.
----------------------------


> Provide JMS forward compatibility
> ---------------------------------
>
>                 Key: WFLY-4585
>                 URL: https://issues.jboss.org/browse/WFLY-4585
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> Older JMS clients (from WildFly 8/9) with HornetQ client libraries must be able to communicate with WildFly 10 and ActiveMQ Artemis.



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

From issues at jboss.org  Wed Dec  6 11:20:39 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:39 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4429) Refactor JCA subsystems
In-Reply-To: <JIRA.12565927.1426471095000@Atlassian.JIRA>
References: <JIRA.12565927.1426471095000@Atlassian.JIRA>
	<JIRA.12565927.1426471095000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565927.1426471095000.87826.1512577239808@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4429.
----------------------------


> Refactor JCA subsystems
> -----------------------
>
>                 Key: WFLY-4429
>                 URL: https://issues.jboss.org/browse/WFLY-4429
>             Project: WildFly
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>            Priority: Critical
>             Fix For: 10.0.0.Alpha4
>
>
> Make use of PASSIVE services in :jca:, :datasources: and :resource-adapters:



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

From issues at jboss.org  Wed Dec  6 11:20:39 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:39 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4569) EntityBean instances are
 leaked from pool on certain exceptions
In-Reply-To: <JIRA.12570086.1430226779000@Atlassian.JIRA>
References: <JIRA.12570086.1430226779000@Atlassian.JIRA>
	<JIRA.12570086.1430226779000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570086.1430226779000.87829.1512577239975@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4569.
----------------------------


> EntityBean instances are leaked from pool on certain exceptions
> ---------------------------------------------------------------
>
>                 Key: WFLY-4569
>                 URL: https://issues.jboss.org/browse/WFLY-4569
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.0.Final, 9.0.0.Beta2, 9.0.0.CR1
>            Reporter: Alexey Makhmutov
>            Assignee: Alexey Makhmutov
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> Entity beans instances may not be returned to the pool after certain exceptions, which may lead to pool exhaustion.
> Currently, following two cases are discovered:
> # If any exception is thrown from ejbCreate method (e.g. duplicate record was found in the database), then bean instance won?t be returned to the pool, as there are no try-finally statements around call to ejbCreate in EntityBeanEjbCreateMethodInterceptor/EntityBeanRemoteViewInstanceFactory classes for this call.
> # If runtime exception (such as EJBException) is thrown from business method, then instance won?t be returned to the pool, as it will be marked as discarded by EntityBeanAssociatingInterceptor and both ReferenceCountingEntityCache/TransactionLocalEntityCache cache implementations just ignores discarded instance on release call.
> These problems actually make impossible using of pooled instances with Entity beans, as number of used beans from pool will be steadily increasing in production until pool is exhausted and clients start getting ?Failed to acquire permit? exceptions.
> Here is the set of integration tests, which examines the described behavior: https://github.com/Lerm/jboss-as/commit/f3eadd96d84dabc0a8b9c6c866ccfd5fe52720fd



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


From issues at jboss.org  Wed Dec  6 11:20:40 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:40 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5244) bean-validation quickstart
 fails to validate due to non-compliant arquillian.xml
In-Reply-To: <JIRA.12583361.1441085658000@Atlassian.JIRA>
References: <JIRA.12583361.1441085658000@Atlassian.JIRA>
	<JIRA.12583361.1441085658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583361.1441085658000.87833.1512577240215@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5244.
----------------------------


> bean-validation quickstart fails to validate due to non-compliant arquillian.xml
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-5244
>                 URL: https://issues.jboss.org/browse/WFLY-5244
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rob Stryker
>            Assignee: Jason Greene
>             Fix For: 10.0.0.CR1
>
>
> bean-validation quickstart fails to validate in arquillian.xml. 
> The arquillian_1_0.xsd file includes the following:
> {code}
>     <element name="container">
>         <complexType>
>             <choice minOccurs="1" maxOccurs="unbounded">
>                 <element ref="tns:configuration" minOccurs="0"  maxOccurs="1" />
>                 <!--
>                 <element ref="tns:dependencies" minOccurs="0" maxOccurs="1" />
>                 -->
>                 <element ref="tns:protocol" minOccurs="0" maxOccurs="unbounded" />
>             </choice>
>             <attribute name="qualifier" type="string" use="required" />
>             <attribute name="default" type="boolean" use="optional" default="false" />
>             <attribute name="mode" use="optional" default="suite">
>                 <simpleType>
>                     <restriction base="string">
>                         <enumeration value="suite" />
>                         <enumeration value="class" />
>                         <enumeration value="manual" />
>                         <enumeration value="custom" />
>                     </restriction>
>                 </simpleType>
>             </attribute>
>         </complexType>
>         <unique name="unique-protocol-within-container">
>             <annotation>
>                 <documentation>
>                     @type must be unique between all
>                     protocols in a container.
>                 </documentation>
>             </annotation>
>             <selector xpath="tns:protocol" />
>             <field xpath="@type" />
>         </unique>
>     </element>
> {code}
> The arquillian.xml included in the example includes the following:
> {code}
>     <container qualifier="jboss" default="true">
>         <!-- By default, arquillian will use the JBOSS_HOME environment variable.  Alternatively, the configuration below can be uncommented. -->
>         <!--<configuration> -->
>         <property name="jbossHome">C:/tools/wildfly-9.0.0.Final</property>
>         <!--</configuration> -->
>     </container>
> {code}
> Validation error is that "property" is not a valid sub-element, which is true based on the xsd file. 



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

From issues at jboss.org  Wed Dec  6 11:20:40 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:40 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5346) Upgrade to Hibernate Search
	5.5.0.Final
In-Reply-To: <JIRA.12584964.1442326509000@Atlassian.JIRA>
References: <JIRA.12584964.1442326509000@Atlassian.JIRA>
	<JIRA.12584964.1442326509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584964.1442326509000.87836.1512577240273@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5346.
----------------------------


> Upgrade to Hibernate Search 5.5.0.Final
> ---------------------------------------
>
>                 Key: WFLY-5346
>                 URL: https://issues.jboss.org/browse/WFLY-5346
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JPA / Hibernate
>            Reporter: Gunnar Morling
>            Assignee: Gunnar Morling
>             Fix For: 10.0.0.CR1
>
>
> Hibernate Search 5.5.0.Final was released earlier today.



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

From issues at jboss.org  Wed Dec  6 11:20:40 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:40 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5337) NPE when restarting
	Infinispan transport
In-Reply-To: <JIRA.12584831.1442240970000@Atlassian.JIRA>
References: <JIRA.12584831.1442240970000@Atlassian.JIRA>
	<JIRA.12584831.1442240970000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584831.1442240970000.87841.1512577240514@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5337.
----------------------------


> NPE when restarting Infinispan transport
> ----------------------------------------
>
>                 Key: WFLY-5337
>                 URL: https://issues.jboss.org/browse/WFLY-5337
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>
> This is actually due to a bug in Infinispan.  Infinispan's JGroupsTransport inappropriately sets its channel to null during stop(), even if a channel was provided to the constructor.
> {noformat}
> 10:10:34,923 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 71) MSC000001: Failed to start service jboss.infinispan.server.default: org.jboss.msc.service.StartException in service jboss.infinispan.server.default: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
> 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
> 	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)
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
> 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:248)
> 	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:618)
> 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
> 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
> 	at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
> 	at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
> 	... 4 more
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
> 	at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> 	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> 	... 13 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.clustering.infinispan.ChannelTransport.initChannel(ChannelTransport.java:84)
> 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:350)
> 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> 	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.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> 	... 18 more
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:20:40 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:40 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5231) [Migration operation] [Web to
 Undertow] Web - access-log and its directory attributes are not migrated
In-Reply-To: <JIRA.12583150.1440770419000@Atlassian.JIRA>
References: <JIRA.12583150.1440770419000@Atlassian.JIRA>
	<JIRA.12583150.1440770419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583150.1440770419000.87845.1512577240714@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5231.
----------------------------


> [Migration operation] [Web to Undertow] Web - access-log and its directory attributes are not migrated
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5231
>                 URL: https://issues.jboss.org/browse/WFLY-5231
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> When migrating access-log via {{:migrate}} and access-log contains directory definition, the properties {{relative-to}} and {{path}} are not migrated.
> Web subsystem snippet:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default" native="false">
>     <virtual-server name="default" enable-welcome-root="true">
>         <alias name="localhost"/>
>         <alias name="example.com"/>
>         <access-log resolve-hosts="true" prefix="test" rotate="false">
>             <directory relative-to="jboss.server.log.dir" path="testvs/vs"/>
>         </access-log>
>     </virtual-server>
> </subsystem>
> {code}
> access log part expected to be migrated as 
> {code:xml}
> <access-log rotate="false" prefix="test" directory="testvs/vs" relative-to="jboss.server.log.dir" />
> {code}
> instead it is migrated without the {{directory}} and {{relative-to}} attributes:
> <access-log rotate="false" prefix="test"/>



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

From issues at jboss.org  Wed Dec  6 11:20:40 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:40 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5089) Upgrade Narayana to
	5.2.2.Final
In-Reply-To: <JIRA.12580963.1439377664000@Atlassian.JIRA>
References: <JIRA.12580963.1439377664000@Atlassian.JIRA>
	<JIRA.12580963.1439377664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580963.1439377664000.87850.1512577240798@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5089.
----------------------------


> Upgrade Narayana to 5.2.2.Final
> -------------------------------
>
>                 Key: WFLY-5089
>                 URL: https://issues.jboss.org/browse/WFLY-5089
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 10.0.0.Beta2
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:40 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:40 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3171) Increase default state
	transfer timeout
In-Reply-To: <JIRA.12536164.1395840490000@Atlassian.JIRA>
References: <JIRA.12536164.1395840490000@Atlassian.JIRA>
	<JIRA.12536164.1395840490000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536164.1395840490000.87855.1512577240996@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3171.
----------------------------


> Increase default state transfer timeout
> ---------------------------------------
>
>                 Key: WFLY-3171
>                 URL: https://issues.jboss.org/browse/WFLY-3171
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.CR1
>
>
> The current state transfer timeout is 1 minute.  Now that Infinispan uses non-blocking state transfer, we should bump this to 4 minutes, in line with Infinispan's defaults.
> Don't forget to include transformers for old model versions.



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

From issues at jboss.org  Wed Dec  6 11:20:41 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:41 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5313) Upgrade to Hibernate Search
 5.5.0.CR1 and Apache Lucene 5.3.0
In-Reply-To: <JIRA.12584439.1441814154000@Atlassian.JIRA>
References: <JIRA.12584439.1441814154000@Atlassian.JIRA>
	<JIRA.12584439.1441814154000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584439.1441814154000.87858.1512577241237@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5313.
----------------------------


> Upgrade to Hibernate Search 5.5.0.CR1 and Apache Lucene 5.3.0
> -------------------------------------------------------------
>
>                 Key: WFLY-5313
>                 URL: https://issues.jboss.org/browse/WFLY-5313
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JPA / Hibernate
>            Reporter: Sanne Grinovero
>            Assignee: Sanne Grinovero
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:41 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:41 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4709) Invalid Last-Modified header
In-Reply-To: <JIRA.12573408.1433160070000@Atlassian.JIRA>
References: <JIRA.12573408.1433160070000@Atlassian.JIRA>
	<JIRA.12573408.1433160070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573408.1433160070000.87864.1512577241347@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4709.
----------------------------


> Invalid Last-Modified header
> ----------------------------
>
>                 Key: WFLY-4709
>                 URL: https://issues.jboss.org/browse/WFLY-4709
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>         Environment: Windows Server 2008
>            Reporter: Davy De Durpel
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> After 2 months of use Wildfly suddenly started to send an invalid Last-Modified header.  Normally it should be in the format:
> Fri, 10 Oct 2014 19:35:55 GMT
> But sometimes it sends:
> Fri, 10 Oct 2014 21:35:55 CEST
> Or even:
> Fri, 10 Oct 2014 21:35:55 CEST GMT
> The URLConnection.getLastModified() method cannot handle these 2 last formats as it uses an old and deprecated Date.parse(..) method.
> A restart of the service fixes the issue for a few hours after which it reappears but not for all requests.  We switched back to JBoss 7.1.1 and the issue disappeared completely so we're pretty sure that it's a bug in WildFly.  No updates were done to windows, java and Wildfly that could have triggered the issue.  We noticed the issue because we have a java applet running at the customer side.  We use URLConnection to download some files based on the last modification date of these files.  Browsers don't seem to be affected by the issue.



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

From issues at jboss.org  Wed Dec  6 11:20:41 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:41 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4294) remove RUNTIME stage for
 :enable :disable operation for (xa)datasource
In-Reply-To: <JIRA.12561958.1422519020000@Atlassian.JIRA>
References: <JIRA.12561958.1422519020000@Atlassian.JIRA>
	<JIRA.12561958.1422519020000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561958.1422519020000.87870.1512577241743@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4294.
----------------------------


> remove RUNTIME stage for :enable :disable operation for (xa)datasource
> ----------------------------------------------------------------------
>
>                 Key: WFLY-4294
>                 URL: https://issues.jboss.org/browse/WFLY-4294
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 10.0.0.Beta1
>
>
> Those operations will no more supported in next version of WF. They will stay in MODEL stage to permit domain administration on older version server, but RUNTIME stage will be removed and operation will fail.
> Also enabled attribute will be updated to maintain consistent behavior



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

From issues at jboss.org  Wed Dec  6 11:20:42 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:42 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4602) HttpServletRequest#logout
 doesn't fully clear security context
In-Reply-To: <JIRA.12570903.1430921675000@Atlassian.JIRA>
References: <JIRA.12570903.1430921675000@Atlassian.JIRA>
	<JIRA.12570903.1430921675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570903.1430921675000.87876.1512577242068@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4602.
----------------------------


> HttpServletRequest#logout doesn't fully clear security context
> --------------------------------------------------------------
>
>                 Key: WFLY-4602
>                 URL: https://issues.jboss.org/browse/WFLY-4602
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.0.CR1
>            Reporter: Arjan t
>            Assignee: Stuart Douglas
>              Labels: authentication, security, security-context
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> After having authenticated (via JASPIC or otherwise), calling {{HttpServletRequest#logout}} and then requesting the caller/user principal (all within the same request), Undertow (via e.g. WildFly 8.2 or 9.0rc1) will correctly clear out the principal for the web context, but will NOT clear out the principal for the EJB context.
> The problem seems to be that {{io.undertow.security.impl.SecurityContextImpl.logout()}} doesn't do anything with the security context that is used by the EJB container among others.
> It now just contains the following:
> {code:java}
> this.account = null;
> this.mechanismName = null;
> this.authenticationState = AuthenticationState.NOT_ATTEMPTED;
> {code}
> Added the following code just before this seems to work:
> {code:java}
> // Clear old context
> SecurityContextAssociation.clearSecurityContext();
> SecurityRolesAssociation.setSecurityRoles(null);
> 	            		
> // Set a new one in case re-authentication is done within the same thread
> SecurityContext securityContext = SecurityContextFactory.createSecurityContext("other");
> exchange.putAttachment(SECURITY_CONTEXT_ATTACHMENT, securityContext);
> SecurityContextAssociation.setSecurityContext(securityContext);
> // (existing clearing code)
> this.account = null;
> this.mechanismName = null;
> this.authenticationState = AuthenticationState.NOT_ATTEMPTED;
> {code}
> Do note that this code uses the hardcoded domain "other". Except by using reflection I couldn't obtain the actual domain name at this point. The reflective code I used was:
> {code:java}
> String securityDomain = "other";
> if (identityManager instanceof JAASIdentityManagerImpl) {
>     try {
>         Field securityDomainContextField = JAASIdentityManagerImpl.class.getDeclaredField("securityDomainContext");
>         securityDomainContextField.setAccessible(true);
>         SecurityDomainContext securityDomainContext = (SecurityDomainContext) securityDomainContextField.get(identityManager);
>         securityDomain = securityDomainContext.getAuthenticationManager().getSecurityDomain();
>     } catch (NoSuchFieldException | SecurityException | IllegalArgumentException | IllegalAccessException e) {
>         logger.log(Level.SEVERE, "Can't obtain name of security domain, using 'other' now", e);
>     }
> }
> {code}



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

From issues at jboss.org  Wed Dec  6 11:20:42 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:42 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5061) Tables for JDBC Batch
 repository are created twice
In-Reply-To: <JIRA.12580378.1438783025000@Atlassian.JIRA>
References: <JIRA.12580378.1438783025000@Atlassian.JIRA>
	<JIRA.12580378.1438783025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580378.1438783025000.87879.1512577242259@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5061.
----------------------------


> Tables for JDBC Batch repository are created twice
> --------------------------------------------------
>
>                 Key: WFLY-5061
>                 URL: https://issues.jboss.org/browse/WFLY-5061
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>            Priority: Critical
>             Fix For: 10.0.0.Beta1
>
>
> The constructor of org.wildfly.extension.batch.jberet.job.repository.JdbcJobRepositoryService is called twice: https://github.com/wildfly/wildfly/blob/80247ada8e7daa46660c732c4fc927e26f055d76/batch/extension-jberet/src/main/java/org/wildfly/extension/batch/jberet/job/repository/JdbcJobRepositoryService.java#L69 (both lines 56 and 69 typically get executed). Two threads then race to create the tables. 
> Some databases can deal with it (those which support IF NOT EXISTS clause in the CREATE TABLE query). But where this is not used, creating a JDBC Batch repository fails with
> {noformat}
> 15:21:31,526 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 29) MSC000001: Failed to start service org.wildfy.batch.job.repository.jdbc: org.jboss.msc.service.StartException in service org.wildfy.batch.job.repository.jdbc: WFLYBATCH000011: Failed to create JDBC job repository.
> 	at org.wildfly.extension.batch.jberet.job.repository.JdbcJobRepositoryService.lambda$start$1(JdbcJobRepositoryService.java:59)
> 	at org.wildfly.extension.batch.jberet.job.repository.JdbcJobRepositoryService$$Lambda$12/1223050080.run(Unknown Source)
> 	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)
> Caused by: javax.batch.operations.BatchRuntimeException: JBERET000624: Failed to create tables for batch job repository database product name Adaptive Server Enterprise with DDL sql/jberet-sybase.ddl
> 	at org.jberet.repository.JdbcRepository.createTables(JdbcRepository.java:281)
> 	at org.jberet.repository.JdbcRepository.<init>(JdbcRepository.java:205)
> 	at org.jberet.repository.JdbcRepository.<init>(JdbcRepository.java:167)
> 	at org.wildfly.extension.batch.jberet.job.repository.JdbcJobRepositoryService.lambda$start$1(JdbcJobRepositoryService.java:56)
> 	... 5 more
> Caused by: java.sql.BatchUpdateException: JZ0BE: BatchUpdateException: Error occurred while executing batch statement: There is already an object named 'JOB_INSTANCE' in the database.
> 	at com.sybase.jdbc4.jdbc.ErrorMessage.raiseBatchUpdateException(ErrorMessage.java:1300)
> 	at com.sybase.jdbc4.jdbc.SybStatement.batchLoop(SybStatement.java:2134)
> 	at com.sybase.jdbc4.jdbc.SybStatement.sendBatch(SybStatement.java:1924)
> 	at com.sybase.jdbc4.jdbc.SybStatement.executeBatch(SybStatement.java:1882)
> 	at com.sybase.jdbc4.jdbc.SybStatement.executeBatch(SybStatement.java:1691)
> 	at org.jboss.jca.adapters.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:1174)
> 	at org.jberet.repository.JdbcRepository.createTables(JdbcRepository.java:279)
> 	... 8 more
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:20:42 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:42 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5308) Failed to start service due
 to IllegalStateException: Duplicate key during application deployment
In-Reply-To: <JIRA.12584398.1441802434000@Atlassian.JIRA>
References: <JIRA.12584398.1441802434000@Atlassian.JIRA>
	<JIRA.12584398.1441802434000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584398.1441802434000.87885.1512577242476@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5308.
----------------------------


>  Failed to start service due to IllegalStateException: Duplicate key during application deployment 
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5308
>                 URL: https://issues.jboss.org/browse/WFLY-5308
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>
> EAP 7.0.0.DR9
> Scenario: failover-ejb-ejbremote-undeploy-dist-async
> During application deployment (after failover), perf20 logged this error:
> {code}
> [JBossINF] [0m[0m15:36:10,604 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
> [JBossINF] [0m[0m15:36:10,608 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 86) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> [JBossINF] [0m[0m15:36:10,611 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 84) WFLYCLINF0002: Started dist cache from web container
> [JBossINF] [0m[0m15:36:10,612 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
> [JBossINF] [0m[31m15:36:10,613 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.ejb.remoting.connector.client-mappings.installer: org.jboss.msc.service.StartException in service jboss.ejb.remoting.connector.client-mappings.installer: Failed to start service
> [JBossINF] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: java.lang.IllegalStateException: Duplicate key [org.jboss.as.network.ClientMapping at 44b990d8]
> [JBossINF] 	at java.util.stream.Collectors.lambda$throwingMerger$152(Collectors.java:133)
> [JBossINF] 	at java.util.stream.Collectors$$Lambda$58/796953906.apply(Unknown Source)
> [JBossINF] 	at java.util.HashMap.merge(HashMap.java:1245)
> [JBossINF] 	at java.util.stream.Collectors.lambda$toMap$210(Collectors.java:1320)
> [JBossINF] 	at java.util.stream.Collectors$$Lambda$60/415494469.accept(Unknown Source)
> [JBossINF] 	at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> [JBossINF] 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> [JBossINF] 	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> [JBossINF] 	at java.util.Iterator.forEachRemaining(Iterator.java:116)
> [JBossINF] 	at org.infinispan.stream.impl.spliterators.IteratorAsSpliterator.forEachRemaining(IteratorAsSpliterator.java:150)
> [JBossINF] 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512)
> [JBossINF] 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502)
> [JBossINF] 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> [JBossINF] 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> [JBossINF] 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> [JBossINF] 	at org.infinispan.stream.impl.local.AbstractLocalCacheStream.collect(AbstractLocalCacheStream.java:256)
> [JBossINF] 	at org.infinispan.stream.impl.TerminalFunctions$CollectorFunction.apply(TerminalFunctions.java:1035)
> [JBossINF] 	at org.infinispan.stream.impl.TerminalFunctions$CollectorFunction.apply(TerminalFunctions.java:1025)
> [JBossINF] 	at org.infinispan.stream.impl.termop.SegmentRetryingOperation.innerPerformOperation(SegmentRetryingOperation.java:68)
> [JBossINF] 	at org.infinispan.stream.impl.termop.SegmentRetryingOperation.performOperation(SegmentRetryingOperation.java:79)
> [JBossINF] 	at org.infinispan.stream.impl.AbstractCacheStream.performOperationRehashAware(AbstractCacheStream.java:306)
> [JBossINF] 	at org.infinispan.stream.impl.AbstractCacheStream.performOperation(AbstractCacheStream.java:252)
> [JBossINF] 	at org.infinispan.stream.impl.DistributedCacheStream.collect(DistributedCacheStream.java:324)
> [JBossINF] 	at org.wildfly.clustering.server.registry.CacheRegistry.getEntries(CacheRegistry.java:110)
> [JBossINF] 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.registryAdded(LocalEjbReceiver.java:447)
> [JBossINF] 	at org.jboss.as.ejb3.remote.RegistryCollectorService.add(RegistryCollectorService.java:54)
> [JBossINF] 	at org.jboss.as.ejb3.remote.RegistryInstallerService.start(RegistryInstallerService.java:60)
> [JBossINF] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [JBossINF] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [JBossINF] 	... 3 more
> [JBossINF] 
> [JBossINF] [0m[31m15:36:10,625 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "clusterbench-ee7.ear")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [
> [JBossINF]     "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.LocalStatefulSB.START is missing [jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.LocalStatefulSB.cache]",
> [JBossINF]     "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.RemoteStatefulSBImpl.START is missing [jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.RemoteStatefulSBImpl.cache]"
> [JBossINF] ]}
> [JBossINF] [0m[31m15:36:10,627 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: 
> [JBossINF] {"WFLYCTL0180: Services with missing/unavailable dependencies" => [
> [JBossINF]     "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.LocalStatefulSB.START is missing [jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.LocalStatefulSB.cache]",
> [JBossINF]     "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.RemoteStatefulSBImpl.START is missing [jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.RemoteStatefulSBImpl.cache]"
> [JBossINF] ]}
> {code}
> Which ends up with WFLYSRV0021: *Deploy of deployment "clusterbench-ee7.ear" was rolled back*.
> In this very same testrun, there was another issue with application deployment on perf18, may be related: JBEAP-1041 
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-undeploy-dist-async/5/console-perf20/



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

From issues at jboss.org  Wed Dec  6 11:20:42 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:42 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4748) Singleton service fails to
 start after repetitive cluster split with "Failed to reach quorum of 1"
In-Reply-To: <JIRA.12573978.1433492548000@Atlassian.JIRA>
References: <JIRA.12573978.1433492548000@Atlassian.JIRA>
	<JIRA.12573978.1433492548000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573978.1433492548000.87892.1512577242775@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4748.
----------------------------


> Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4748
>                 URL: https://issues.jboss.org/browse/WFLY-4748
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
>            Reporter: Tomas Hofman
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Alpha6
>
>
> When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1".
> This only happens after the second and other successive splits. After the first split both nodes execute the service correctly.
> After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'.
> I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted():
> {code}
> public void viewAccepted(View view) {
>     // ...
>     for (Listener listener: this.listeners) {
>         listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView);
>     }
> }
> {code}
> This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified.



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

From issues at jboss.org  Wed Dec  6 11:20:43 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:43 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4146) Cache add operation should
 automatically create its child resources
In-Reply-To: <JIRA.12558587.1417537468000@Atlassian.JIRA>
References: <JIRA.12558587.1417537468000@Atlassian.JIRA>
	<JIRA.12558587.1417537468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558587.1417537468000.87898.1512577243018@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4146.
----------------------------


> Cache add operation should automatically create its child resources
> -------------------------------------------------------------------
>
>                 Key: WFLY-4146
>                 URL: https://issues.jboss.org/browse/WFLY-4146
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Alpha6
>
>
> There is effectively no difference between the behavior of a cache that does not contain a given child resource (e.g. transaction, locking, etc) and one that contains the child resource, but with default attribute values.
> Consequently, the cache add operation should automatically create these resources (and the cache remove operation should automatically remove them).  We can treat the child add operations as no-ops, and the child remove operations as a series of undefine-attribute operations.



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

From issues at jboss.org  Wed Dec  6 11:20:43 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:43 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4861) Unable to establish HTTP/2
 connection via plain http (non https)
In-Reply-To: <JIRA.12576899.1435844258000@Atlassian.JIRA>
References: <JIRA.12576899.1435844258000@Atlassian.JIRA>
	<JIRA.12576899.1435844258000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576899.1435844258000.87902.1512577243095@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4861.
----------------------------


> Unable to establish HTTP/2 connection via plain http (non https)
> ----------------------------------------------------------------
>
>                 Key: WFLY-4861
>                 URL: https://issues.jboss.org/browse/WFLY-4861
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 10.0.0.Alpha5
>
>
> HTTP/2 doesn't work over plain http (non-https) even when {{http-listener}}'s {{enable-http2}} option is set to {{true}}, see [1].
> I am using Http2 client from netty for trying whether it is possible to establish HHTP/2 connection via upgrade.
> [1] 
> {code:xml}
>  <server name="default-server">
>                 <http-listener name="default" socket-binding="http" enable-http2="true" redirect-socket="https"/>
>                 <https-listener name="https" socket-binding="https" security-realm="https" enable-http2="true"/>
>                 <host name="default-host" alias="localhost">
>                     <location name="/" handler="welcome-content"/>
>                     <filter-ref name="server-header"/>
>                     <filter-ref name="x-powered-by-header"/>
>                 </host>
>             </server>
> {code}



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

From issues at jboss.org  Wed Dec  6 11:20:43 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:43 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4730) Undertow mod_cluster proxy
 does not offer any Client HTTPS configuration
In-Reply-To: <JIRA.12573351.1433001061000@Atlassian.JIRA>
References: <JIRA.12573351.1433001061000@Atlassian.JIRA>
	<JIRA.12573351.1433001061000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573351.1433001061000.87908.1512577243332@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4730.
----------------------------


> Undertow mod_cluster proxy does not offer any Client HTTPS configuration
> ------------------------------------------------------------------------
>
>                 Key: WFLY-4730
>                 URL: https://issues.jboss.org/browse/WFLY-4730
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
>            Reporter: Michal Karm Babacek
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 10.0.0.Alpha3
>
>
> Undertow mod_cluster proxy acts both as a *server* and as a *client* in relation to its workers.
> While the *server* configuration is quite straightforward:
> {code:xml}
> +++
> <system-properties>
>     <property name="javax.net.ssl.trustStore" value="/vault/ca-cert.jks"/>
>     <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> </system-properties>
> +++
> <security-realm name="UndertowRealm">
>     <server-identities>
>         <ssl>
>             <keystore path="/vault/server-cert-key.jks"  keystore-password="tomcat" alias="javaserver" key-password="tomcat"/>
>         </ssl>
>     </server-identities>
> </security-realm>
> +++
> <https-listener name="https" socket-binding="https" security-realm="UndertowRealm"/>
> +++
> {code}
> with having {{management-socket-binding="https"}} and {{advertise-protocol="https"}} set; it seems there is no way to configure certs and keys for the *client* role of the Undertow mod_cluster proxy implementation.
> With the current implementation, *worker* can connect to the Undertow mod_cluster proxy, i.e. it can send {{CONFIG}} and {{STATUS}} MCMP messages, but when the Undertow mod_cluster proxy needs to act as a *client*, sending {{STATUS-RSP}} message to the *worker*, it does not have the necessary HTTPS setup:
> {noformat}
> DEBUG [io.undertow] (default I/O-5) UT005055: HttpClientPingTask run for connection: https://192.168.0.122:8544/?#
> DEBUG [io.undertow.server.handlers.proxy.ProxyHandler] (default I/O-5) No proxy target for request to https://192.168.0.122:8443/
> DEBUG [io.undertow] (default task-7) UT005056: Received node load in STATUS message, node jvmRoute: worker-1, load: 80
> DEBUG [io.undertow.request] (default I/O-5) Failed to connect: java.io.IOException: UT000065: SSL must be specified to connect to a https URL
>     at io.undertow.client.http.HttpClientProvider.connect(HttpClientProvider.java:93)
>     at io.undertow.client.UndertowClient.connect(UndertowClient.java:158)
>     at io.undertow.server.handlers.proxy.ProxyConnectionPool.openConnection(ProxyConnectionPool.java:233)
>     at io.undertow.server.handlers.proxy.ProxyConnectionPool.connect(ProxyConnectionPool.java:446)
>     at io.undertow.server.handlers.proxy.mod_cluster.NodePingUtil$1.run(NodePingUtil.java:140)
>     at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
>     at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
> {noformat}
> The HTTPS communication between Undertow mod_cluster proxy and its workers needs to be bidirectional.
> If I'm just missing any obvious configuration option, please, shout, throw rocks and close this JIRA :)
> Thank you for your time looking into it.



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

From issues at jboss.org  Wed Dec  6 11:20:43 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:43 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4740) Move JMS high-level commands
 to the messaging extension
In-Reply-To: <JIRA.12573840.1433406778000@Atlassian.JIRA>
References: <JIRA.12573840.1433406778000@Atlassian.JIRA>
	<JIRA.12573840.1433406778000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573840.1433406778000.87913.1512577243633@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4740.
----------------------------


> Move JMS high-level commands to the messaging extension
> -------------------------------------------------------
>
>                 Key: WFLY-4740
>                 URL: https://issues.jboss.org/browse/WFLY-4740
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha2
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha3
>
>
> This is the pending WildFly issue for WFCORE-733 to move the high-level JMS cli commands to the messaging extension instead of having them hard-coded in the wildfly-cli module



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

From issues at jboss.org  Wed Dec  6 11:20:43 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:43 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5254) Upgrade Infinispan to
	8.0.0.Final
In-Reply-To: <JIRA.12583463.1441122181000@Atlassian.JIRA>
References: <JIRA.12583463.1441122181000@Atlassian.JIRA>
	<JIRA.12583463.1441122181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583463.1441122181000.87918.1512577243876@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5254.
----------------------------


> Upgrade Infinispan to 8.0.0.Final
> ---------------------------------
>
>                 Key: WFLY-5254
>                 URL: https://issues.jboss.org/browse/WFLY-5254
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:44 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:44 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5280) Connector attribute
 max-save-post-size is neither migrated nor migration writing is shown
In-Reply-To: <JIRA.12584012.1441369938000@Atlassian.JIRA>
References: <JIRA.12584012.1441369938000@Atlassian.JIRA>
	<JIRA.12584012.1441369938000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584012.1441369938000.87922.1512577244098@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5280.
----------------------------


> Connector attribute max-save-post-size is neither migrated nor migration writing is shown
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5280
>                 URL: https://issues.jboss.org/browse/WFLY-5280
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> When migrating http connector, which has defined attribute {{max-save-post-size}} no warning that it is not possible to migrate the {{max-save-post-size}} is printed.



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

From issues at jboss.org  Wed Dec  6 11:20:44 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:44 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4817) WildFly (Undertow) fails to
 include jsp static content when "If-Modified-Since" header is used
In-Reply-To: <JIRA.12575900.1434990084000@Atlassian.JIRA>
References: <JIRA.12575900.1434990084000@Atlassian.JIRA>
	<JIRA.12575900.1434990084000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575900.1434990084000.87927.1512577244428@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4817.
----------------------------


> WildFly (Undertow) fails to include jsp static content when "If-Modified-Since" header is used
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4817
>                 URL: https://issues.jboss.org/browse/WFLY-4817
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.0.CR2
>            Reporter: Marco Mondini
>            Assignee: Stuart Douglas
>             Fix For: 9.0.1.Final, 10.0.0.Alpha6
>
>
> WildFly (Undertow) doesn't correctly include static content in jsp when tag is used in combination of "If-Modified-Since" header as per https://issues.jboss.org/browse/UNDERTOW-476.
> Upgrading Undertow to version 1.2.9.Final will fix the issue.



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

From issues at jboss.org  Wed Dec  6 11:20:44 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:44 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4628) Add ability to restart and
	stop batch jobs
In-Reply-To: <JIRA.12571505.1431470033000@Atlassian.JIRA>
References: <JIRA.12571505.1431470033000@Atlassian.JIRA>
	<JIRA.12571505.1431470033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571505.1431470033000.87930.1512577244480@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4628.
----------------------------


> Add ability to restart and stop batch jobs
> ------------------------------------------
>
>                 Key: WFLY-4628
>                 URL: https://issues.jboss.org/browse/WFLY-4628
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Batch
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Blocker
>             Fix For: 10.0.0.Beta1
>
>
> Currently there is only a way to view batch jobs for a deployment with in the batch subsystem management. There should be a way to restart and stop running jobs as well.



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

From issues at jboss.org  Wed Dec  6 11:20:44 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:44 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5283) [Migration operation] [Web to
 Undertow] Connector's protocol names via FQCN are not recognized as
 migratable
In-Reply-To: <JIRA.12584024.1441376701000@Atlassian.JIRA>
References: <JIRA.12584024.1441376701000@Atlassian.JIRA>
	<JIRA.12584024.1441376701000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584024.1441376701000.87934.1512577244585@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5283.
----------------------------


> [Migration operation] [Web to Undertow] Connector's protocol names via FQCN are not recognized as migratable
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5283
>                 URL: https://issues.jboss.org/browse/WFLY-5283
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> In Web subsystem there is possible to define protocol either via its API name (e.g. {{HTTP/1.1}}, where it is taken default implementation of given API) or via FQCN.
> In case of {{HTTP/1.1}} there are several implementations:
> JIO => {{org.apache.coyote.http11.Http11Protocol}} - default protocol
> NIO2 => {{org.apache.coyote.http11.Http11NioProtocol}} - required to be used to be able to use WebSockets
> APR (default with natives) => {{org.apache.coyote.http11.Http11AprProtocol}}
> The {{:migrate}} operation should also recognize these FQCN as valid HTTP/HTTPS protocols and migrate them correctly.
> Note: in case of AJP there are these FQCN:
> {{org.apache.coyote.ajp.AjpAprProtocol}} - AJP with natives enabled
> {{org.apache.coyote.ajp.AjpProtocol}} AJP without natives



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

From issues at jboss.org  Wed Dec  6 11:20:44 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:44 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4801) When expression is used in
 jndi name attribute of datasource then test-connection-in-pool operation is
 not working
In-Reply-To: <JIRA.12575432.1434602136000@Atlassian.JIRA>
References: <JIRA.12575432.1434602136000@Atlassian.JIRA>
	<JIRA.12575432.1434602136000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575432.1434602136000.87938.1512577244863@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4801.
----------------------------


>  When expression is used in jndi name attribute of datasource then test-connection-in-pool operation is not working
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4801
>                 URL: https://issues.jboss.org/browse/WFLY-4801
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 10.0.0.Alpha3
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>             Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>
> {noformat}
> Description of problem:
> ========================
> - Expression is added in the datasource JNDI name attribute as below:
> -----
>   <datasource jndi-name="${ds}" pool-name="ExampleDS" enabled="true" use-java-context="true">
> -----
> - Value for the expression is passed to the JBoss server during the JBoss startup as below:
> -----
>   ./standalone.sh -Dds=java:jboss/datasources/ExampleDS
> -----
> - In the server.log file below is the information regarding the datasource.
> -----
>   INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [${ds}]
> ----- 
> - Test the datasource using the below command and here is the result:
> ----
> [standalone at localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:test-connection-in-pool()
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS010440: failed to invoke operation: JBAS010442: failed to match pool. Check JndiName: java:/${ds}",
>     "rolled-back" => true
> }
> ----
> - Here is the information regarding the JNDI name attribute:
> ----
> [standalone at localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-resource-description(recursive=true)
> {
>     "outcome" => "success",
>     "result" => {
>         	  :
>             "jndi-name" => {
>                 "type" => STRING,
>                 "description" => "Specifies the JNDI name for the datasource",
>                 "expressions-allowed" => true,
>                 "nillable" => false,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
> 		  :
> }
> -----
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:20:45 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:45 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5036) The
 infinispan-directory-provider jar is packaged in multiple modules
In-Reply-To: <JIRA.12579840.1438251793000@Atlassian.JIRA>
References: <JIRA.12579840.1438251793000@Atlassian.JIRA>
	<JIRA.12579840.1438251793000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579840.1438251793000.87946.1512577245198@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5036.
----------------------------


> The infinispan-directory-provider jar is packaged in multiple modules
> ---------------------------------------------------------------------
>
>                 Key: WFLY-5036
>                 URL: https://issues.jboss.org/browse/WFLY-5036
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JPA / Hibernate
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Sanne Grinovero
>            Assignee: Sanne Grinovero
>            Priority: Minor
>             Fix For: 10.0.0.CR1
>
>
> The module integrating Infinispan storage for Hibernate Search indexes is currently duplicated, as a result of a rename of the project ownership and it being moved from Hibernate to Infinispan for maintenance, and not all dependencies being in synch yet.
> This problem might be resolved by the move to feature packs, but creating this issue to make sure of that.
> As far as I know the problem doesn't result in any lack of functionality, other than taking some unnecessary space.



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

From issues at jboss.org  Wed Dec  6 11:20:45 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:45 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5100) Server does not start when
 transaction subsystem configures journal object store
In-Reply-To: <JIRA.12581129.1439474408000@Atlassian.JIRA>
References: <JIRA.12581129.1439474408000@Atlassian.JIRA>
	<JIRA.12581129.1439474408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581129.1439474408000.87952.1512577245482@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5100.
----------------------------


> Server does not start when transaction subsystem configures journal object store
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-5100
>                 URL: https://issues.jboss.org/browse/WFLY-5100
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 10.0.0.Beta1, 10.0.0.Beta2, 10.0.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Amos Feng
>            Priority: Blocker
>             Fix For: 10.0.0.Beta2
>
>         Attachments: standalone.xml
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start.
> For WFLY 10.Beta1 there is trouble of attributes naming - see WFLY-5078. But either when used old naming [1] (hornetq instead of activemq) the server fails to start [2].
> For WFLY 10.CR1 the naming works fine and {{use-journal-store}} works when used via jboss-cli.sh but the server starts still with the errors.
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-journal-store, value=true)
> {code}
> [2]
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>  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: com.arjuna.ats.arjuna.exceptions.FatalError: ARJUNA012135: Could not create Store type: com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor
>  at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:155)
>  at com.arjuna.ats.arjuna.objectstore.StoreManager.getActionStore(StoreManager.java:110)
>  at com.arjuna.ats.arjuna.objectstore.StoreManager.getRecoveryStore(StoreManager.java:67)
>  at com.arjuna.ats.internal.jta.recovery.arjunacore.CommitMarkableResourceRecordRecoveryModule.<init>(CommitMarkableResourceRecordRecoveryModule.java:156)
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>  at java.lang.Class.newInstance(Class.java:442)
>  at com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:135)
>  at com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClassesWithInit(ClassloadingUtility.java:192)
>  at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getRecoveryModules(RecoveryEnvironmentBean.java:444)
>  at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModules(PeriodicRecovery.java:865)
>  at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.<init>(PeriodicRecovery.java:121)
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:107)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:477)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:132)
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:112)
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.create(RecoveryManagerService.java:54)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:119)
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>  ... 3 more
> Caused by: java.lang.NoClassDefFoundError: org/apache/activemq/artemis/core/journal/SequentialFileFactory
>  at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor.<init>(HornetqObjectStoreAdaptor.java:78)
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>  at java.lang.Class.newInstance(Class.java:442)
>  at com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:135)
>  at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:151)
>  ... 24 more
> Caused by: java.lang.ClassNotFoundException: org.apache.activemq.artemis.core.journal.SequentialFileFactory from [Module "org.jboss.jts:main" from local module loader @707f7052 (finder: local module finder @11028347 (roots: /home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules,/home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules/system/layers/base))]
>  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)
>  ... 32 more
>  ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaRecoveryManager" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service
>     Caused by: com.arjuna.ats.arjuna.exceptions.FatalError: ARJUNA012135: Could not create Store type: com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor
>     Caused by: java.lang.NoClassDefFoundError: org/apache/activemq/artemis/core/journal/SequentialFileFactory
>     Caused by: java.lang.ClassNotFoundException: org.apache.activemq.artemis.core.journal.SequentialFileFactory from [Module \"org.jboss.jts:main\" from local module loader @707f7052 (finder: local module finder @11028347 (roots: /home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules,/home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules/system/layers/base))]"}}
> INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186:   Services which failed to start:      service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service
> {code}
> The reason is explained in comment
> https://issues.jboss.org/browse/WFLY-5078?focusedCommentId=13098047#comment-13098047



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

From issues at jboss.org  Wed Dec  6 11:20:45 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:45 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4918) Remove default-stack usage
 and make stack required/explicit per channel
In-Reply-To: <JIRA.12577929.1436821778000@Atlassian.JIRA>
References: <JIRA.12577929.1436821778000@Atlassian.JIRA>
	<JIRA.12577929.1436821778000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577929.1436821778000.87956.1512577245609@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4918.
----------------------------


> Remove default-stack usage and make stack required/explicit per channel
> -----------------------------------------------------------------------
>
>                 Key: WFLY-4918
>                 URL: https://issues.jboss.org/browse/WFLY-4918
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.Beta2
>
>
> We discussed with Paul earlier today to go the way of making this explicit per channel, since currently there is a info when booting the default ha profiles:
> 18:06:44,039 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.



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

From issues at jboss.org  Wed Dec  6 11:20:45 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:45 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4880) Permission names are not
 persisted in the domain model
In-Reply-To: <JIRA.12577218.1436273020000@Atlassian.JIRA>
References: <JIRA.12577218.1436273020000@Atlassian.JIRA>
	<JIRA.12577218.1436273020000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577218.1436273020000.87965.1512577245833@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4880.
----------------------------


> Permission names are not persisted in the domain model
> ------------------------------------------------------
>
>                 Key: WFLY-4880
>                 URL: https://issues.jboss.org/browse/WFLY-4880
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security Manager
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Josef Cacek
>            Assignee: Kabir Khan
>            Priority: Blocker
>             Fix For: 10.0.0.Alpha6
>
>
> Permission names used in the {{security-manager}} subsystem model are not persisted. It can simply lead to non-bootable server configuration.
> Expected behavior:
> The names used for permission model nodes are persisted in the model (e.g. in an {{alias}} attribute).



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

From issues at jboss.org  Wed Dec  6 11:20:45 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:45 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4567) Remove support for
	jboss-as-jca_1_0.xsd
In-Reply-To: <JIRA.12570081.1430225650000@Atlassian.JIRA>
References: <JIRA.12570081.1430225650000@Atlassian.JIRA>
	<JIRA.12570081.1430225650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570081.1430225650000.87969.1512577245907@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4567.
----------------------------


> Remove support for jboss-as-jca_1_0.xsd
> ---------------------------------------
>
>                 Key: WFLY-4567
>                 URL: https://issues.jboss.org/browse/WFLY-4567
>             Project: WildFly
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Alpha5
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:46 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:46 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4563) Review log categories and
 remove/change where necessary
In-Reply-To: <JIRA.12569898.1430157696000@Atlassian.JIRA>
References: <JIRA.12569898.1430157696000@Atlassian.JIRA>
	<JIRA.12569898.1430157696000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569898.1430157696000.87973.1512577246063@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4563.
----------------------------


> Review log categories and remove/change where necessary
> -------------------------------------------------------
>
>                 Key: WFLY-4563
>                 URL: https://issues.jboss.org/browse/WFLY-4563
>             Project: WildFly
>          Issue Type: Task
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 10.0.0.Alpha4
>
>
> Look for situations like;
> {code}
> MessagingLogger ROOT_LOGGER = Logger.getMessageLogger(MessagingLogger.class, "org.jboss.as.messaging");
> MessagingLogger MESSAGING_LOGGER = Logger.getMessageLogger(MessagingLogger.class, "org.jboss.messaging");
> {code}
> Possibly change all to org.wildfly.*.



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

From issues at jboss.org  Wed Dec  6 11:20:46 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:46 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3663) WildFly should manage JGroups
 and Infinispan thread pools by default
In-Reply-To: <JIRA.12547430.1406238369000@Atlassian.JIRA>
References: <JIRA.12547430.1406238369000@Atlassian.JIRA>
	<JIRA.12547430.1406238369000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547430.1406238369000.87979.1512577246195@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3663.
----------------------------


> WildFly should manage JGroups and Infinispan thread pools by default
> --------------------------------------------------------------------
>
>                 Key: WFLY-3663
>                 URL: https://issues.jboss.org/browse/WFLY-3663
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.Beta1
>
>
> In our default configuration, both JGroups and Infinispan manage their own thread pools.  Unfortunately, both projects do not handle thread pool lifecycle  so well.  Both projects use ExecutorService.shutdownNow() to end their thread pool lifecycles.  This means that a channel or cache can stop, but still leave active threads running (albeit interrupted).  We should have services that manage the lifecycle of our thread pools which ensure that all threads have terminated during Service.stop().
> This causes occasional OOMs in the Windows CI testsuite runs, due to too many threads lying around.



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

From issues at jboss.org  Wed Dec  6 11:20:46 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:46 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4392) Make use of TCCL in ARQ
 ManagedContainer configurable
In-Reply-To: <JIRA.12564406.1425026524000@Atlassian.JIRA>
References: <JIRA.12564406.1425026524000@Atlassian.JIRA>
	<JIRA.12564406.1425026524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564406.1425026524000.87982.1512577246263@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4392.
----------------------------


> Make use of TCCL in ARQ ManagedContainer configurable
> -----------------------------------------------------
>
>                 Key: WFLY-4392
>                 URL: https://issues.jboss.org/browse/WFLY-4392
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> In WildFly it is considerred intended behaviour that test code gets called with the TCCL set to the test deployment. IMHO this shadows potential problems when the functionality under test is not called from an ARQ test case (i.e. from an normal javaee endpoint)
> For Camel integration this behaviour is not acceptable.
> CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/340



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

From issues at jboss.org  Wed Dec  6 11:20:46 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:46 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4668) mod-cluster configure via CLI
 may end with msg: Failed to start service Caused by:
 java.lang.NullPointerException"
In-Reply-To: <JIRA.12572561.1432542824000@Atlassian.JIRA>
References: <JIRA.12572561.1432542824000@Atlassian.JIRA>
	<JIRA.12572561.1432542824000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572561.1432542824000.87987.1512577246404@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4668.
----------------------------


> mod-cluster configure via CLI may end with msg: Failed to start service Caused by: java.lang.NullPointerException"
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4668
>                 URL: https://issues.jboss.org/browse/WFLY-4668
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.0.CR1
>            Reporter: Jan Stourac
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha3
>
>
> When setting up mod-cluster via CLI then msg Failed to start service Caused by: java.lang.NullPointerException" may appear.
> Particular file where exception is thrown is: ModClusterService.java, line 90 . Reason for exception is that advertise socket binding has to have set multicast address also (mod cluster just expect it is set it does not check it). In case multicat address is set then adding mod-cluster filter is successful.
> I would expect that more reasonable message is print to user instead of generic NPE.



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

From issues at jboss.org  Wed Dec  6 11:20:46 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:46 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4902) Upgrade to Artemis 1.1.0
In-Reply-To: <JIRA.12577667.1436527141000@Atlassian.JIRA>
References: <JIRA.12577667.1436527141000@Atlassian.JIRA>
	<JIRA.12577667.1436527141000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577667.1436527141000.87992.1512577246615@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4902.
----------------------------


> Upgrade to Artemis 1.1.0
> ------------------------
>
>                 Key: WFLY-4902
>                 URL: https://issues.jboss.org/browse/WFLY-4902
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:47 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5146) Expose Infinispan's
 remoteCommandExecutor thread pool configuration
In-Reply-To: <JIRA.12582002.1440076145000@Atlassian.JIRA>
References: <JIRA.12582002.1440076145000@Atlassian.JIRA>
	<JIRA.12582002.1440076145000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582002.1440076145000.87996.1512577247296@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5146.
----------------------------


> Expose Infinispan's remoteCommandExecutor thread pool configuration
> -------------------------------------------------------------------
>
>                 Key: WFLY-5146
>                 URL: https://issues.jboss.org/browse/WFLY-5146
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:47 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5070) @WebServlet.loadOnStartup=0
 doesn't startup the servlet
In-Reply-To: <JIRA.12580651.1438955957000@Atlassian.JIRA>
References: <JIRA.12580651.1438955957000@Atlassian.JIRA>
	<JIRA.12580651.1438955957000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580651.1438955957000.88001.1512577247418@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5070.
----------------------------


> @WebServlet.loadOnStartup=0 doesn't startup the servlet
> -------------------------------------------------------
>
>                 Key: WFLY-5070
>                 URL: https://issues.jboss.org/browse/WFLY-5070
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Tomas Hofman
>            Assignee: Tomas Hofman
>             Fix For: 10.0.0.Beta2
>
>
> Servlet is autostarted only with loadOnStartup value > 0. Specification says value can be >= 0.



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

From issues at jboss.org  Wed Dec  6 11:20:47 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5200) Reading transport protocol
 metrics fails with "Protocol UDP not found in current stack"
In-Reply-To: <JIRA.12582561.1440516842000@Atlassian.JIRA>
References: <JIRA.12582561.1440516842000@Atlassian.JIRA>
	<JIRA.12582561.1440516842000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582561.1440516842000.88005.1512577247597@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5200.
----------------------------


> Reading transport protocol metrics fails with "Protocol UDP not found in current stack"
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-5200
>                 URL: https://issues.jboss.org/browse/WFLY-5200
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.CR1
>
>
> {noformat}
> [standalone at localhost:9990 /] /subsystem=jgroups/channel=ee/protocol=UDP:read-attribute(name=timer-queue_max_size
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCLJG0019: Protocol UDP not found in current stack",
>     "rolled-back" => true
> }{noformat}



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

From issues at jboss.org  Wed Dec  6 11:20:47 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:47 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4975) Can't create colocated HA
 topology with JGroups discovery
In-Reply-To: <JIRA.12578715.1437473136000@Atlassian.JIRA>
References: <JIRA.12578715.1437473136000@Atlassian.JIRA>
	<JIRA.12578715.1437473136000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578715.1437473136000.88015.1512577247984@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4975.
----------------------------


> Can't create colocated HA topology with JGroups discovery
> ---------------------------------------------------------
>
>                 Key: WFLY-4975
>                 URL: https://issues.jboss.org/browse/WFLY-4975
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>             Fix For: 10.0.0.CR1
>
>         Attachments: standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> Hi, I tried to start two nodes in colocated topology with JGroups as discovery method (it's defalut for EAP7), but i'm not able to do it. After both nodes are up, this exception starts spamming in logs: 
> java.io.NotSerializableException: org.jgroups.JChannel
> 10:56:50,187 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> 10:56:50,188 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> 10:56:50,188 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> 10:56:50,188 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> 10:56:50,188 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> 10:56:50,188 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> 10:56:50,189 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> 10:56:50,189 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> 10:56:50,189 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> 10:56:50,189 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> 10:56:50,189 ERROR [stderr] (default I/O-5) 	at java.util.ArrayList.writeObject(ArrayList.java:747)
> 10:56:50,189 ERROR [stderr] (default I/O-5) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:56:50,190 ERROR [stderr] (default I/O-5) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 10:56:50,190 ERROR [stderr] (default I/O-5) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:56:50,190 ERROR [stderr] (default I/O-5) 	at java.lang.reflect.Method.invoke(Method.java:483)
> 10:56:50,190 ERROR [stderr] (default I/O-5) 	at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> 10:56:50,190 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> 10:56:50,190 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> 10:56:50,191 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> 10:56:50,191 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> 10:56:50,191 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> 10:56:50,191 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> 10:56:50,191 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> 10:56:50,192 ERROR [stderr] (default I/O-5) 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> 10:56:50,192 ERROR [stderr] (default I/O-5) 	at org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy(ConfigurationImpl.java:1528)
> 10:56:50,192 ERROR [stderr] (default I/O-5) 	at org.apache.activemq.artemis.core.server.cluster.ha.ColocatedHAManager.activateReplicatedBackup(ColocatedHAManager.java:190)
> 10:56:50,192 ERROR [stderr] (default I/O-5) 	at org.apache.activemq.artemis.core.server.cluster.ha.ColocatedHAManager.activateBackup(ColocatedHAManager.java:104)
> 10:56:50,192 ERROR [stderr] (default I/O-5) 	at org.apache.activemq.artemis.core.server.impl.ColocatedActivation$1.handlePacket(ColocatedActivation.java:141)
> 10:56:50,193 ERROR [stderr] (default I/O-5) 	at org.apache.activemq.artemis.core.server.cluster.ClusterController$ClusterControllerChannelHandler.handlePacket(ClusterController.java:424)
> 10:56:50,193 ERROR [stderr] (default I/O-5) 	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:652)
> 10:56:50,193 ERROR [stderr] (default I/O-5) 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:402)
> 10:56:50,193 ERROR [stderr] (default I/O-5) 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:379)
> 10:56:50,193 ERROR [stderr] (default I/O-5) 	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
> 10:56:50,193 ERROR [stderr] (default I/O-5) 	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> 10:56:50,194 ERROR [stderr] (default I/O-5) 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> 10:56:50,194 ERROR [stderr] (default I/O-5) 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> 10:56:50,194 ERROR [stderr] (default I/O-5) 	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
> 10:56:50,194 ERROR [stderr] (default I/O-5) 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> 10:56:50,194 ERROR [stderr] (default I/O-5) 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> 10:56:50,194 ERROR [stderr] (default I/O-5) 	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
> 10:56:50,195 ERROR [stderr] (default I/O-5) 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> 10:56:50,195 ERROR [stderr] (default I/O-5) 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> 10:56:50,195 ERROR [stderr] (default I/O-5) 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 10:56:50,195 ERROR [stderr] (default I/O-5) 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 10:56:50,195 ERROR [stderr] (default I/O-5) 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
> 10:56:50,196 ERROR [stderr] (default I/O-5) 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> Is there anything wrong with my configs?
> I think that problem is in non serializable org.jgroups.JChannel



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


From issues at jboss.org  Wed Dec  6 11:20:48 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5221)
 TimerServiceTimerService.getTimers() returns not only the associated timer
 entries for the current Bean
In-Reply-To: <JIRA.12582818.1440679445000@Atlassian.JIRA>
References: <JIRA.12582818.1440679445000@Atlassian.JIRA>
	<JIRA.12582818.1440679445000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582818.1440679445000.88020.1512577248255@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5221.
----------------------------


> TimerServiceTimerService.getTimers() returns not only the associated timer entries for the current Bean
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5221
>                 URL: https://issues.jboss.org/browse/WFLY-5221
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Wolf-Dieter Fink
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 10.0.0.CR1
>
>
> According to the spec [1] the getTimers() method must only return timers associated to the current EJB.
> This is a huge issue if timers are cancled by this collection as it will remove all timers!
> [1] https://docs.oracle.com/javaee/6/api/javax/ejb/TimerService.html#getTimers%28%29



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

From issues at jboss.org  Wed Dec  6 11:20:48 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4339) NPE when deployment contains
 a *-ds.xml in domain
In-Reply-To: <JIRA.12562963.1423675997000@Atlassian.JIRA>
References: <JIRA.12562963.1423675997000@Atlassian.JIRA>
	<JIRA.12562963.1423675997000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562963.1423675997000.88024.1512577248479@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4339.
----------------------------


> NPE when deployment contains a *-ds.xml in domain
> -------------------------------------------------
>
>                 Key: WFLY-4339
>                 URL: https://issues.jboss.org/browse/WFLY-4339
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.2.0.Final
>            Reporter: James Perkins
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Beta2
>
>
> If you build the [kitchen-sink quickstart|https://github.com/wildfly/quickstart/tree/master/kitchensink] and attempt to deploy to domain servers you'll see the following error. Same deployment works fine in standalone.
> {code}
> [Server:server-one] 09:25:06,563 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-14) MSC000001: Failed to start service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: WFLYJCA0033: Error during the deployment of java:jboss/datasources/KitchensinkQuickstartDS
> [Server:server-one] 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:142)
> [Server:server-two] 09:25:06,563 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: WFLYJCA0033: Error during the deployment of java:jboss/datasources/KitchensinkQuickstartDS
> [Server:server-two] 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:142)
> [Server:server-two] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:server-two] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:server-two] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-two] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-two] 	at java.lang.Thread.run(Thread.java:745)
> [Server:server-two] Caused by: java.lang.NullPointerException
> [Server:server-two] 	at org.jboss.as.connector.services.driver.registry.DriverRegistryImpl.getInstalledDriver(DriverRegistryImpl.java:93)
> [Server:server-two] 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:324)
> [Server:server-two] 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:135)
> [Server:server-two] 	... 5 more
> [Server:server-two] 
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] 	at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] Caused by: java.lang.NullPointerException
> [Server:server-one] 	at org.jboss.as.connector.services.driver.registry.DriverRegistryImpl.getInstalledDriver(DriverRegistryImpl.java:93)
> [Server:server-one] 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:324)
> [Server:server-one] 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:135)
> [Server:server-one] 	... 5 more
> {code}



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

From issues at jboss.org  Wed Dec  6 11:20:48 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5278) default path for SSO should
	be /
In-Reply-To: <JIRA.12583994.1441365427000@Atlassian.JIRA>
References: <JIRA.12583994.1441365427000@Atlassian.JIRA>
	<JIRA.12583994.1441365427000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583994.1441365427000.88028.1512577248560@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5278.
----------------------------


> default path for SSO should be /
> --------------------------------
>
>                 Key: WFLY-5278
>                 URL: https://issues.jboss.org/browse/WFLY-5278
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Tomaz Cerar
>            Priority: Blocker
>             Fix For: 10.0.0.CR1
>
>
> Single Sign On doesn't work for two web applications with different context name.



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

From issues at jboss.org  Wed Dec  6 11:20:48 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:48 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5260) Cannot inject
 TransactionSynchronizationRegistry into CDI bean
In-Reply-To: <JIRA.12583538.1441186683000@Atlassian.JIRA>
References: <JIRA.12583538.1441186683000@Atlassian.JIRA>
	<JIRA.12583538.1441186683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583538.1441186683000.88032.1512577248916@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5260.
----------------------------


> Cannot inject TransactionSynchronizationRegistry into CDI bean
> --------------------------------------------------------------
>
>                 Key: WFLY-5260
>                 URL: https://issues.jboss.org/browse/WFLY-5260
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Tomas Remes
>            Assignee: Martin Kouba
>             Fix For: 10.0.0.CR1
>
>
> It's not possible to inject TransactionSynchronizationRegistry to CDI bean as follows:
> {code}
> @ApplicationScoped
> public class CdiBean {
>     @Resource
>     TransactionSynchronizationRegistry transactionSynchronizationRegistry;
> }
> {code}
> This results to:
> {noformat}
> java.lang.IllegalArgumentException: WFLYWELD0049: Error injecting resource into CDI managed bean. Can't find a resource named java:comp/env/org.jboss.as.test.integration.weld.jta.CdiBean/transactionSynchronizationRegistry defined on javax.transaction.TransactionSynchronizationRegistry org.jboss.as.test.integration.weld.jta.CdiBean.transactionSynchronizationRegistry
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:210)
> 	at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices$1.createResource(WeldResourceInjectionServices.java:158)
> 	at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
> 	at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
> 	at org.jboss.weld.util.Beans.injectEEFields(Beans.java:351)
> 	at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)
> 	at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
> 	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$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141)
> 	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.as.test.integration.weld.jta.CdiBean$Proxy$_$$_WeldClientProxy.isTransactionSynchronizationRegistryInjected(Unknown Source)
> 	at org.jboss.as.test.integration.weld.jta.TransactionSynchronizationRegistryInjectionTestCase.testTransactionSynchronizationRegistryIsInjected(TransactionSynchronizationRegistryInjectionTestCase.java:30)
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:20:49 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4779) Persisting an empty list []
 gets read as a list with empty string [""] resulting in
 IllegalArgumentException
In-Reply-To: <JIRA.12574881.1434137434000@Atlassian.JIRA>
References: <JIRA.12574881.1434137434000@Atlassian.JIRA>
	<JIRA.12574881.1434137434000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574881.1434137434000.88036.1512577249146@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4779.
----------------------------


> Persisting an empty list [] gets read as a list with empty string [""] resulting in IllegalArgumentException
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4779
>                 URL: https://issues.jboss.org/browse/WFLY-4779
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 9.0.0.CR2, 10.0.0.Alpha2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>             Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>
> Affects at least infinispan aliases and modcluster proxies...
> (20:09:22) rhusar: pferraro: https://gist.github.com/rhusar/5eef22d7a6479f042a5d#file-gistfile1-txt-L23
> (20:09:34) rhusar: pferraro: if i write an empy list, read it back -> empty list
> (20:09:57) rhusar: pferraro: if i use the default writeAttribute, reload, read it back and i have a list of size 1 containing empty String..
> (20:23:23) rhusar: pferraro: alright, this is also "broken" in the infiinispan subsystem aliases
> (20:23:24) rhusar: pferraro: 20:22:55,775 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 40) WFLYCTL0013: Operation ("add") failed - address: ([
> (20:23:24) rhusar:     ("subsystem" => "infinispan"),
> (20:23:24) rhusar:     ("cache-container" => "hibernate")
> (20:23:24) rhusar: ]): java.lang.IllegalArgumentException: Empty name segment is not allowed for infinispan
> (20:23:24) rhusar: 	at org.jboss.msc.service.ServiceName.of(ServiceName.java:90)
> (20:23:24) rhusar: 	at org.jboss.msc.service.ServiceName.append(ServiceName.java:117)
> (20:23:24) rhusar: 	at org.wildfly.clustering.infinispan.spi.service.CacheContainerServiceName$1.getServiceName(CacheContainerServiceName.java:35)
> (20:23:24) rhusar: 	at org.jboss.as.clustering.infinispan.subsystem.CacheContainerBuilder.build(CacheContainerBuilder.java:79)
> (20:23:24) rhusar: 	at org.jboss.as.clustering.infinispan.subsystem.CacheContainerAddHandler.installRuntimeServices(CacheContainerAddHandler.java:165)
> (20:23:24) rhusar: 	at org.jboss.as.clustering.infinispan.subsystem.CacheContainerAddHandler.performRuntime(CacheContainerAddHandler.java:82)
> (20:23:24) rhusar: 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:309)
> (20:23:24) rhusar: 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:130)
> (20:23:24) rhusar: 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:822)
> (20:23:24) rhusar: 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:620)
> (20:23:24) rhusar: 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:373)
> (20:23:24) rhusar: 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:349)
> (20:23:24) rhusar: 	at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359)
> (20:23:24) rhusar: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> (20:23:24) rhusar: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> (20:23:24) rhusar: 	at java.lang.Thread.run(Thread.java:745)
> (20:23:24) rhusar: 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)



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

From issues at jboss.org  Wed Dec  6 11:20:49 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4656) Export dependency for
 "javax.jms.api" in org.jboss.genericjms module
In-Reply-To: <JIRA.12572374.1432212430000@Atlassian.JIRA>
References: <JIRA.12572374.1432212430000@Atlassian.JIRA>
	<JIRA.12572374.1432212430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572374.1432212430000.88043.1512577249464@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4656.
----------------------------


> Export dependency for "javax.jms.api" in org.jboss.genericjms module
> --------------------------------------------------------------------
>
>                 Key: WFLY-4656
>                 URL: https://issues.jboss.org/browse/WFLY-4656
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA, JMS
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> More info in WFLY-4642.
> If deployment with MDB has dependency to module "org.jboss.genericjms" then module "javax.jms.api" is not loaded for the deployment and deploy fails.
> This is a change in module loading behaviour against previous versions of Wildfly/EAP and complicates migration/usability.
> We can avoid this by exporting "javax.jms.api" dependency in "org.jboss.genericjms" module. It should look like:
> {code}
> <module xmlns="urn:jboss:module:1.3" name="org.jboss.genericjms">
>  ...
>     <dependencies>
>      ...
>         <module name="javax.jms.api" slot="main" export="true"/>
>      ...
>     </dependencies>
> </module>
> {code}



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

From issues at jboss.org  Wed Dec  6 11:20:49 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:49 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5143) JGroups subsystem parser
 should not allow thread pool to be defined per protocol
In-Reply-To: <JIRA.12581985.1440073744000@Atlassian.JIRA>
References: <JIRA.12581985.1440073744000@Atlassian.JIRA>
	<JIRA.12581985.1440073744000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581985.1440073744000.88048.1512577249736@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5143.
----------------------------


> JGroups subsystem parser should not allow thread pool to be defined per protocol
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-5143
>                 URL: https://issues.jboss.org/browse/WFLY-5143
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>
> In this case, the parser does not match the schemas.  There are 3 issues here:
>  # Thread pool elements should only be parsed for schema version >= 3.0
>  # Thread pool elements are only valid children of a <transport/> element, but are currently accepted as children of a <protocol/> element.
>  # We should always create thread pool resources, even if xml is undefined - that way the thread pool parameters, as applied to the runtime, are expressed in the model.



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

From issues at jboss.org  Wed Dec  6 11:20:50 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:50 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4964)
 java.lang.IllegalStateException: channel is closed when using JGroups for
 HA replication
In-Reply-To: <JIRA.12578560.1437384083000@Atlassian.JIRA>
References: <JIRA.12578560.1437384083000@Atlassian.JIRA>
	<JIRA.12578560.1437384083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578560.1437384083000.88054.1512577250001@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4964.
----------------------------


> java.lang.IllegalStateException: channel is closed when using JGroups for HA replication
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-4964
>                 URL: https://issues.jboss.org/browse/WFLY-4964
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> I'm getting this exception when I try to use <replication-master> and JGroups for cluster discovery:
> AMQ222116: unable to start broadcast group bg-group1: java.lang.IllegalStateException: channel is closed
> at org.jgroups.JChannel.checkClosed(JChannel.java:959) [jgroups-3.6.3.Final.jar:3.6.3.Final]
> at org.jgroups.JChannel._preConnect(JChannel.java:548) [jgroups-3.6.3.Final.jar:3.6.3.Final]
> at org.jgroups.JChannel.connect(JChannel.java:288) [jgroups-3.6.3.Final.jar:3.6.3.Final]
> at org.jgroups.JChannel.connect(JChannel.java:279) [jgroups-3.6.3.Final.jar:3.6.3.Final]
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint$JChannelWrapper.connect(JGroupsBroadcastEndpoint.java:211) [artemis-core-client-1.0.0.jar:1.0.0]
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.internalOpen(JGroupsBroadcastEndpoint.java:115) [artemis-core-client-1.0.0.jar:1.0.0]
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.openBroadcaster(JGroupsBroadcastEndpoint.java:101) [artemis-core-client-1.0.0.jar:1.0.0]
> at org.apache.activemq.artemis.core.server.cluster.impl.BroadcastGroupImpl.start(BroadcastGroupImpl.java:105) [artemis-server-1.0.0.jar:1.0.0]
> at org.apache.activemq.artemis.core.server.cluster.ClusterManager.start(ClusterManager.java:288) [artemis-server-1.0.0.jar:1.0.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1904) [artemis-server-1.0.0.jar:1.0.0]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:104) [artemis-server-1.0.0.jar:1.0.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:416) [artemis-server-1.0.0.jar:1.0.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:414) [artemis-jms-server-1.0.0.jar:1.0.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:173) [wildfly-messaging-activemq-10.0.0.Alpha4-redhat-1.jar:10.0.0.Alpha4-redhat-1]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:60) [wildfly-messaging-activemq-10.0.0.Alpha4-redhat-1.jar:10.0.0.Alpha4-redhat-1]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:94) [wildfly-messaging-activemq-10.0.0.Alpha4-redhat-1.jar:10.0.0.Alpha4-redhat-1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_05]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.0.Final.jar:2.2.0.Final]
> This issue seems to be the same as: https://issues.apache.org/jira/browse/ARTEMIS-103



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


From issues at jboss.org  Wed Dec  6 11:20:50 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:50 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4797) Adjustments for
	ordered-child-resources
In-Reply-To: <JIRA.12575295.1434538919000@Atlassian.JIRA>
References: <JIRA.12575295.1434538919000@Atlassian.JIRA>
	<JIRA.12575295.1434538919000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575295.1434538919000.88057.1512577250057@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4797.
----------------------------


> Adjustments for ordered-child-resources
> ---------------------------------------
>
>                 Key: WFLY-4797
>                 URL: https://issues.jboss.org/browse/WFLY-4797
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 10.0.0.Alpha5
>
>
> https://github.com/wildfly/wildfly-core/pull/813 for WFCORE-759 deprecates some methods, which need to be removed once PR 813 has been merged and released. These changes will come in a future core release, but first we need to update the usage in Full (currently only in JGroups).
> Also, the @Override should be uncommented for https://github.com/wildfly/wildfly/pull/7611/files



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

From issues at jboss.org  Wed Dec  6 11:20:50 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:50 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4529) Port jboss-as-ee_1_2.xsd to
	WildFly
In-Reply-To: <JIRA.12568730.1429286343000@Atlassian.JIRA>
References: <JIRA.12568730.1429286343000@Atlassian.JIRA>
	<JIRA.12568730.1429286343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568730.1429286343000.88061.1512577250304@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4529.
----------------------------


> Port jboss-as-ee_1_2.xsd to WildFly
> -----------------------------------
>
>                 Key: WFLY-4529
>                 URL: https://issues.jboss.org/browse/WFLY-4529
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: EE
>            Reporter: Darran Lofthouse
>            Assignee: Richard Opalka
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:50 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:50 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3564) Remove support for
 mixed-domain transforming to < 7.3.0 versions
In-Reply-To: <JIRA.12545164.1404159466000@Atlassian.JIRA>
References: <JIRA.12545164.1404159466000@Atlassian.JIRA>
	<JIRA.12545164.1404159466000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545164.1404159466000.88065.1512577250381@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3564.
----------------------------


> Remove support for mixed-domain transforming to < 7.3.0 versions
> ----------------------------------------------------------------
>
>                 Key: WFLY-3564
>                 URL: https://issues.jboss.org/browse/WFLY-3564
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>
> (Deliberately currently unscheduled as I don't want this to become a priority unless there is clear need.)
> We will not support WF 9 mixed domains with slaves running releases prior to 7.3 / EAP 6.2 (and maybe later) so we should remove the various transformer logic meant to deal with the fact that slaves in those early releases did not provide information about the version of subsystems they are running.
> KnownVersions can go, as can bits of logic that logged warns or errors instead of failing the transformation because the master could not know if the slave was going to ignore the resource.



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

From issues at jboss.org  Wed Dec  6 11:20:51 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:51 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1247) graceful shutdown
In-Reply-To: <JIRA.12416315.1281436249000@Atlassian.JIRA>
References: <JIRA.12416315.1281436249000@Atlassian.JIRA>
	<JIRA.12416315.1281436249000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12416315.1281436249000.88093.1512577251696@Atlassian.JIRA>


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

Kabir Khan closed WFLY-1247.
----------------------------


> graceful shutdown
> -----------------
>
>                 Key: WFLY-1247
>                 URL: https://issues.jboss.org/browse/WFLY-1247
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Beta1
>
>
> We need to define a clear contract between these networking services and the services that use them in order to be able to perform a graceful shutdown of remote connectors.



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

From issues at jboss.org  Wed Dec  6 11:20:52 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:52 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4811) Add batch-jberet subsystem to
 replace the original batch subsystem
In-Reply-To: <JIRA.12575746.1434737392000@Atlassian.JIRA>
References: <JIRA.12575746.1434737392000@Atlassian.JIRA>
	<JIRA.12575746.1434737392000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575746.1434737392000.88100.1512577252222@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4811.
----------------------------


> Add batch-jberet subsystem to replace the original batch subsystem
> ------------------------------------------------------------------
>
>                 Key: WFLY-4811
>                 URL: https://issues.jboss.org/browse/WFLY-4811
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Batch
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 10.0.0.Beta1
>
>
> The original batch subsystem will not work well with capabilities and requirements. It's also fairly limited in the validation it can offer for the job repositories.
> Current model:
> {code}
> {
>     "outcome" => "success",
>     "result" => {
>         "job-repository-type" => "in-memory",
>         "job-repository" => {"jdbc" => {"jndi-name" => undefined}},
>         "thread-factory" => undefined,
>         "thread-pool" => {"batch" => {
>             "keepalive-time" => {
>                 "time" => 30L,
>                 "unit" => "SECONDS"
>             },
>             "max-threads" => 10,
>             "name" => "batch",
>             "thread-factory" => undefined
>         }}
>     }
> }
> {code}
> The {{job-repository-type}} will be removed as well as the {{job-repository=jdbc}}. A new {{jdbc-job-repository}} and {{in-memory-job-repository}} resource will be added. There will also be a {{default-job-repository}} which will accept a name from one of the defined job repositories.
> The {{jndi-name}} will no longer be used and a {{data-source}} name will be used for the JDBC job repository. For example resource value might be {{ExampleDS}}.
> A new deployment descriptor will be added to allow a user to defined a job repository configured on the subsystem.
> Due to these changes the persisted XML will likely need some small alterations. Mainly ensuring a name attribute is persisted and multiple repositories are allowed to be defined.
> The current batch subsystem will remain. It will allow the server to boot with old configurations, but the default with be the new {{batch-jberet}} subsystem.



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

From issues at jboss.org  Wed Dec  6 11:20:52 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:52 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4799) cancelled ejb timers persist
 in data/timer-service-data
In-Reply-To: <JIRA.12575324.1434544277000@Atlassian.JIRA>
References: <JIRA.12575324.1434544277000@Atlassian.JIRA>
	<JIRA.12575324.1434544277000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575324.1434544277000.88104.1512577252299@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4799.
----------------------------


> cancelled ejb timers persist in data/timer-service-data
> -------------------------------------------------------
>
>                 Key: WFLY-4799
>                 URL: https://issues.jboss.org/browse/WFLY-4799
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.CR2
>         Environment: linux 4.0.4-303.fc22.x86_64,  java jdk1.8.0_45 and wildfly-9.0.0.CR2
>            Reporter: John Whitley
>            Assignee: jaikiran pai
>              Labels: jboss
>             Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>         Attachments: timertest.tgz
>
>
> I have a Singleton bean which creates a ejb.timer on deployment. Before doing so it cancels any existing timers previously created by the bean for completeness.
> In wildfly 8 the cancelled timers were removed from data/timer-service-data/'bean'. In wildfly 9 CR2, they stay in data/timer-service-data/'bean' and appear to be re-instated on re-deployment



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

From issues at jboss.org  Wed Dec  6 11:20:52 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:52 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4697) EJBClient access to SFSBs
 does not play well with clean shutdown
In-Reply-To: <JIRA.12573154.1432827547000@Atlassian.JIRA>
References: <JIRA.12573154.1432827547000@Atlassian.JIRA>
	<JIRA.12573154.1432827547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573154.1432827547000.88111.1512577252760@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4697.
----------------------------


> EJBClient access to SFSBs does not play well with clean shutdown
> ----------------------------------------------------------------
>
>                 Key: WFLY-4697
>                 URL: https://issues.jboss.org/browse/WFLY-4697
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB, Remoting
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 10.0.0.Alpha4
>
>
> The clean shutdown mechanism allows EJB and web applications to make use of shutdown interceptors to allow the application server to refuse requests when a server is in the process of shutting down. These interceptors are tied to the processing of EJB invocations and web requests.
> In the case of EJBCLient invocations, they arrive at the remoting connector, and undergo some preliminary processing before being sent to the EJB interface in question. When a server is shutting down, EJBCLient invocations can arrive at the RemoteConnector and start processing, even when the EJB interface has been locked down, so to speak.
> I am seeing various types of exceptions arising from this preliminary processing (e.g. NPE on DeploymentRepository lookups) and these get returned to the client as exceptions on the SFSB invocation, before even reaching the SFSB interceptors.
> If the EJBCLient is running in a managed transaction context, these returned exceptions will case the SFSB to be discarded (as the SFSB invocation is considered failed with the exception returned) and the transaction will attempt to rollback. If the rollback processing fails (because the original node in the transaction is down the bean gets removed anyway. The SFSB session state is lost, even if there is another node in the cluster which can support the invocation.
> In short, it looks as though the clean shutdown mechanism needs to be used to also lock down the processing of EJBCLient invocations in some way.
>  



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

From issues at jboss.org  Wed Dec  6 11:20:52 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:52 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4594) Move messaging subsystem to
	legacy/
In-Reply-To: <JIRA.12570828.1430903918000@Atlassian.JIRA>
References: <JIRA.12570828.1430903918000@Atlassian.JIRA>
	<JIRA.12570828.1430903918000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570828.1430903918000.88116.1512577252984@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4594.
----------------------------


> Move messaging subsystem to legacy/
> -----------------------------------
>
>                 Key: WFLY-4594
>                 URL: https://issues.jboss.org/browse/WFLY-4594
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha4
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:53 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:53 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5164) Upgrade Infinispan to
	8.0.0.CR1
In-Reply-To: <JIRA.12582157.1440159890000@Atlassian.JIRA>
References: <JIRA.12582157.1440159890000@Atlassian.JIRA>
	<JIRA.12582157.1440159890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582157.1440159890000.88121.1512577253192@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5164.
----------------------------


> Upgrade Infinispan to 8.0.0.CR1
> -------------------------------
>
>                 Key: WFLY-5164
>                 URL: https://issues.jboss.org/browse/WFLY-5164
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta2
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:53 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:53 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5298) JASPIC verifyResponse is not
 called if proactive authentication is not in use
In-Reply-To: <JIRA.12584311.1441748101000@Atlassian.JIRA>
References: <JIRA.12584311.1441748101000@Atlassian.JIRA>
	<JIRA.12584311.1441748101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584311.1441748101000.88129.1512577253495@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5298.
----------------------------


> JASPIC verifyResponse is not called if proactive authentication is not in use
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-5298
>                 URL: https://issues.jboss.org/browse/WFLY-5298
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:54 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:54 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5112) After removing property empty
 properties tag left in xml cofiguration and server cannot run more.
In-Reply-To: <JIRA.12581086.1439458550000@Atlassian.JIRA>
References: <JIRA.12581086.1439458550000@Atlassian.JIRA>
	<JIRA.12581086.1439458550000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581086.1439458550000.88138.1512577254038@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5112.
----------------------------


> After removing property empty properties tag left in xml cofiguration and server cannot run more.
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5112
>                 URL: https://issues.jboss.org/browse/WFLY-5112
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta1
>         Environment: Unsecured EAP 7.0.0 DR8 in standalone mode with standalone-full-ha profile.
>            Reporter: Patrik Cyprian
>            Assignee: Patrik Cyprian
>            Priority: Blocker
>             Fix For: 10.0.0.Beta2
>
>
> When in IIOP configuration is new property added and server is reloaded, then after removing property and reloading server, server cannot run more because of empty </properties> tag in xml configuration of profile.



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

From issues at jboss.org  Wed Dec  6 11:20:54 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:54 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4732) Potential race in test suite
 where ops can execute before server has reloaded
In-Reply-To: <JIRA.12573703.1433329879000@Atlassian.JIRA>
References: <JIRA.12573703.1433329879000@Atlassian.JIRA>
	<JIRA.12573703.1433329879000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573703.1433329879000.88141.1512577254102@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4732.
----------------------------


> Potential race in test suite where ops can execute before server has reloaded
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-4732
>                 URL: https://issues.jboss.org/browse/WFLY-4732
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.Alpha2
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:54 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:54 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3859) Improve
 ChannelInstanceResourceDefinition.addChannelProtocolMetricsRegistrationStep
In-Reply-To: <JIRA.12552334.1410878666000@Atlassian.JIRA>
References: <JIRA.12552334.1410878666000@Atlassian.JIRA>
	<JIRA.12552334.1410878666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552334.1410878666000.88147.1512577254364@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3859.
----------------------------


> Improve ChannelInstanceResourceDefinition.addChannelProtocolMetricsRegistrationStep
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-3859
>                 URL: https://issues.jboss.org/browse/WFLY-3859
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 10.0.0.Beta1
>
>
> While debugging a test, I noticed this in the test's console output:
> ERROR: WFLYCTL0013: Operation ("some_operation_name") failed - address: ([("subsystem" => "jgroups")]) - failure description: "WFLYCTL0216: Management resource '[(\"subsystem\" => \"jgroups\")]' not found"
> Sep 16, 2014 9:29:35 AM org.jboss.as.controller.AbstractOperationContext executeStep
> That "some_operation_name" visible to users isn't so good.
> A simple fix is to use a more meaningful name.



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

From issues at jboss.org  Wed Dec  6 11:20:54 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:54 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4720) DuplicateServiceException
 when adding a new FORK channel
In-Reply-To: <JIRA.12573517.1433237887000@Atlassian.JIRA>
References: <JIRA.12573517.1433237887000@Atlassian.JIRA>
	<JIRA.12573517.1433237887000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573517.1433237887000.88151.1512577254517@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4720.
----------------------------


> DuplicateServiceException when adding a new FORK channel
> --------------------------------------------------------
>
>                 Key: WFLY-4720
>                 URL: https://issues.jboss.org/browse/WFLY-4720
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> {noformat}
> [standalone at localhost:9990 /] /subsystem=jgroups/channel=ee/fork=myfork:add
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.jgroups.factory.ee is already registered",
>     "rolled-back" => true
> }
> {noformat}
> the problem is fixed in org.jboss.as.clustering.jgroups.subsystem.ForkAddHandler#installRuntimeServices



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

From issues at jboss.org  Wed Dec  6 11:20:54 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:54 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4593) Model-only representation
In-Reply-To: <JIRA.12570827.1430903879000@Atlassian.JIRA>
References: <JIRA.12570827.1430903879000@Atlassian.JIRA>
	<JIRA.12570827.1430903879000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570827.1430903879000.88156.1512577254714@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4593.
----------------------------


> Model-only representation
> -------------------------
>
>                 Key: WFLY-4593
>                 URL: https://issues.jboss.org/browse/WFLY-4593
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha4
>
>
> Refactor the messaging subsystem to use ModelOnlyResource definition and remove all runtime code.
> Remove also the org.hornetq and org.hornetq.ra) modules.
> With WFLY-4584, a org.hornetq.client module is added to represent only the HornetQ client library (required for JMS forward compatibility)



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

From issues at jboss.org  Wed Dec  6 11:20:55 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:55 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3590) Option to disable processing
 of authentication tokens on unsecured resources.
In-Reply-To: <JIRA.12545767.1404754399000@Atlassian.JIRA>
References: <JIRA.12545767.1404754399000@Atlassian.JIRA>
	<JIRA.12545767.1404754399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545767.1404754399000.88163.1512577255115@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3590.
----------------------------


> Option to disable processing of authentication tokens on unsecured resources.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-3590
>                 URL: https://issues.jboss.org/browse/WFLY-3590
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final
>         Environment: Oracle Java 1.8.0_05, Ubuntu 14.04
>            Reporter: Harald Wellmann
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha3
>
>
> WildFly sends a basic authentication challenge and denies access when it shouldn't in the following simple setup:
> {code:xml}
>     <login-config>
>         <auth-method>BASIC</auth-method>
>         <realm-name>test</realm-name>
>     </login-config>
>     
>     <security-constraint>
>         <web-resource-collection>
>             <web-resource-name>all</web-resource-name>
>             <url-pattern>/hello</url-pattern>            
>         </web-resource-collection>
>         <auth-constraint>        
>             <role-name>USER</role-name>
>         </auth-constraint>       
>     </security-constraint>
>     
>     <security-role>
>         <role-name>USER</role-name>
>     </security-role>
> {code}
> {{/hello}} is the only protected URL (mapped to a servlet), other URLs like {{/index.html}} are public.
> When GETting /index.html with an (unneeded) basic authentication header, access is denied:
> {noformat}
> $ curl -v -u foo:bar http://localhost:8080/auth-basic/index.html
> * Hostname was NOT found in DNS cache
> *   Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 8080 (#0)
> * Server auth using Basic with user 'foo'
> > GET /auth-basic/index.html HTTP/1.1
> > Authorization: Basic Zm9vOmJhcg==
> > User-Agent: curl/7.35.0
> > Host: localhost:8080
> > Accept: */*
> > 
> < HTTP/1.1 401 Unauthorized
> < Connection: keep-alive
> * Authentication problem. Ignoring this.
> < WWW-Authenticate: Basic realm="test"
> < X-Powered-By: Undertow/1
> * Server WildFly/8 is not blacklisted
> < Server: WildFly/8
> < Content-Type: text/html;charset=ISO-8859-1
> < Content-Length: 71
> < Date: Mon, 07 Jul 2014 17:28:25 GMT
> < 
> * Connection #0 to host localhost left intact
> <html><head><title>Error</title></head><body>Unauthorized</body></html>
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:20:55 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:55 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4164) New JTS record types are not
 showing up in the CLI
In-Reply-To: <JIRA.12558974.1418117464000@Atlassian.JIRA>
References: <JIRA.12558974.1418117464000@Atlassian.JIRA>
	<JIRA.12558974.1418117464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558974.1418117464000.88171.1512577255770@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4164.
----------------------------


> New JTS record types are not showing up in the CLI
> --------------------------------------------------
>
>                 Key: WFLY-4164
>                 URL: https://issues.jboss.org/browse/WFLY-4164
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI, Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Michael Musgrove
>             Fix For: 10.0.0.Alpha5
>
>
> We need to expose the new JTS record types in the tooling:
> {code}
>     AssumedCompleteHeuristicTransaction
>     AssumedCompleteHeuristicServerTransaction
>     AssumedCompleteTransaction
>     AssumedCompleteServerTransaction
> {code}
> We need these because if a transaction ends up in a heuristic state we can't actually view this using the CLI even though the records are in the object store. This has the consequence that a transaction can remain in the object store indefinitely.



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

From issues at jboss.org  Wed Dec  6 11:20:56 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:56 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5044) Upgrade HAL to 2.8.4
In-Reply-To: <JIRA.12580096.1438560400000@Atlassian.JIRA>
References: <JIRA.12580096.1438560400000@Atlassian.JIRA>
	<JIRA.12580096.1438560400000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580096.1438560400000.88174.1512577256082@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5044.
----------------------------


> Upgrade HAL to 2.8.4
> --------------------
>
>                 Key: WFLY-5044
>                 URL: https://issues.jboss.org/browse/WFLY-5044
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.Beta1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:56 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:56 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4651) Change default locking
 isolation of infinispan caches to READ_COMMITTED
In-Reply-To: <JIRA.12572301.1432163679000@Atlassian.JIRA>
References: <JIRA.12572301.1432163679000@Atlassian.JIRA>
	<JIRA.12572301.1432163679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572301.1432163679000.88179.1512577256335@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4651.
----------------------------


> Change default locking isolation of infinispan caches to READ_COMMITTED
> -----------------------------------------------------------------------
>
>                 Key: WFLY-4651
>                 URL: https://issues.jboss.org/browse/WFLY-4651
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> This will allow concurrent read access to the session using our default configuration.



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

From issues at jboss.org  Wed Dec  6 11:20:56 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:56 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4604) Smoke testsuite fails when
 running under security manager on JDK8
In-Reply-To: <JIRA.12570959.1430986014000@Atlassian.JIRA>
References: <JIRA.12570959.1430986014000@Atlassian.JIRA>
	<JIRA.12570959.1430986014000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570959.1430986014000.88186.1512577256616@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4604.
----------------------------


> Smoke testsuite fails when running under security manager on JDK8
> -----------------------------------------------------------------
>
>                 Key: WFLY-4604
>                 URL: https://issues.jboss.org/browse/WFLY-4604
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security Manager
>    Affects Versions: 9.0.0.CR1
>         Environment: JDK 8 runtime
>            Reporter: Tomaz Cerar
>            Assignee: James Perkins
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> see http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=52198&tab=buildResultsDiv&buildTypeId=WF_PullRequest_LinuxSm
> failed tests:
> {noformat}
> org.jboss.as.test.integration.jsp.JspTagTestCase.test 	
> org.jboss.as.test.integration.web.jsp.taglib.external.ExternalTagLibTestCase.testExternalAndInternalTagLib 
> org.jboss.as.test.integration.web.jsp.taglib.external.ExternalTagLibTestCase.testExternalTagLibOnly
> {noformat}
> {noformat}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(file:/opt/buildAgent/work/a31d203e70e89f90/testsuite/integration/web/target/jbossas/standalone/tmp/external-dependency-only.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader at 1b8fd02")
>     at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:270)
>     at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:172)
>     at java.lang.Class.checkMemberAccess(Class.java:2348)
>     at java.lang.Class.getDeclaredConstructor(Class.java:2177)
>     at org.jboss.as.ee.component.ReflectiveClassIntrospector.createFactory(ReflectiveClassIntrospector.java:22)
>     at org.jboss.as.ee.component.ComponentRegistry.createInstanceFactory(ComponentRegistry.java:76)
>     at org.jboss.as.web.common.WebInjectionContainer.newInstance(WebInjectionContainer.java:67)
>     at org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager.newInstance(UndertowJSPInstanceManager.java:67)
>     at org.apache.jsp.test_jsp._jspx_meth_e_005ftest_005f0(test_jsp.java:83)
>     at org.apache.jsp.test_jsp._jspService(test_jsp.java:61)
>     at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:20:56 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:56 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5297) WildFly/IronJacamar
	1.3.0.Final
In-Reply-To: <JIRA.12584300.1441735040000@Atlassian.JIRA>
References: <JIRA.12584300.1441735040000@Atlassian.JIRA>
	<JIRA.12584300.1441735040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584300.1441735040000.88191.1512577256862@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5297.
----------------------------


> WildFly/IronJacamar 1.3.0.Final
> -------------------------------
>
>                 Key: WFLY-5297
>                 URL: https://issues.jboss.org/browse/WFLY-5297
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:57 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:57 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4514) Remove RuntimeVaultReader
 from WildFly full as it is now in WildFly-Core
In-Reply-To: <JIRA.12568392.1429022109000@Atlassian.JIRA>
References: <JIRA.12568392.1429022109000@Atlassian.JIRA>
	<JIRA.12568392.1429022109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568392.1429022109000.88198.1512577257192@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4514.
----------------------------


> Remove RuntimeVaultReader from WildFly full as it is now in WildFly-Core
> ------------------------------------------------------------------------
>
>                 Key: WFLY-4514
>                 URL: https://issues.jboss.org/browse/WFLY-4514
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Security
>    Affects Versions: 9.0.0.Beta2
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>             Fix For: 10.0.0.Alpha3
>
>
> Once WFCORE-114 has been merged there is no need to keep the RuntimeVaultReader in the security subsystem



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

From issues at jboss.org  Wed Dec  6 11:20:57 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:57 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4932) Ehcache dependency version
 clash in the testsuite
In-Reply-To: <JIRA.12578190.1436973937000@Atlassian.JIRA>
References: <JIRA.12578190.1436973937000@Atlassian.JIRA>
	<JIRA.12578190.1436973937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578190.1436973937000.88201.1512577257426@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4932.
----------------------------


> Ehcache dependency version clash in the testsuite
> -------------------------------------------------
>
>                 Key: WFLY-4932
>                 URL: https://issues.jboss.org/browse/WFLY-4932
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.Beta1
>
>
> We currently have a problem with the transitive ehcache dependency in the WidFly integration testsuite.
> The dependency comes from:
> {noformat}
> [INFO] +- org.wildfly:wildfly-testsuite-shared:jar:10.0.0.Alpha6-SNAPSHOT:test
> ...
> [INFO] |  +- org.apache.directory.server:apacheds-core-annotations:jar:2.0.0-M15:test
> [INFO] |  |  +- org.apache.directory.server:apacheds-core:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-core-shared:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-admin:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-authn:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-authz:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-changelog:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-collective:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-event:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-exception:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-journal:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-normalization:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-operational:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-referral:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-schema:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-subtree:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-interceptors-trigger:jar:2.0.0-M15:test
> [INFO] |  |  |  |  \- org.apache.directory.api:api-ldap-extras-trigger:jar:1.0.0-M20:test
> [INFO] |  |  |  +- org.apache.directory.api:api-ldap-extras-util:jar:1.0.0-M20:test
> [INFO] |  |  |  \- bouncycastle:bcprov-jdk15:jar:140:test
> [INFO] |  |  +- org.apache.directory.server:apacheds-core-api:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.server:apacheds-core-constants:jar:2.0.0-M15:test
> [INFO] |  |  |  +- org.apache.directory.api:api-ldap-client-api:jar:1.0.0-M20:test
> [INFO] |  |  |  +- org.apache.directory.api:api-ldap-extras-aci:jar:1.0.0-M20:test
> [INFO] |  |  |  \- net.sf.ehcache:ehcache-core:jar:2.4.4:test
> ...
> {noformat}
> Now, the issue is that Apache CXF needs EHCache 2.7.1 or greater for WS-Security functionalites. Alternatively, it can properly work *without* EHCache, but in that case EHCache must not be available in the test classpath.
> I tried upgrading the ehcache dependency, but I could not find a version that actually works. Version 2.7.1 is not usable because it pulls a bunch of terracotta components that are not on the jboss maven repository.
> With more recent versions, instead, it looks like some ldap / login functionality do not work; the following tests fail:
> org.jboss.as.test.integration.security.loginmodules.LdapLoginModuleTestCase
> org.jboss.as.test.integration.security.loginmodules.LdapExtLikeAdvancedLdapLMTestCase
> org.jboss.as.test.integration.security.loginmodules.LdapExtLoginModuleTestCase
> org.jboss.as.test.integration.security.loginmodules.LdapExtPasswordCachingTestCase
> with an error message saying
> {noformat}
> 16:49:58,610 ERROR [org.jboss.as.arquillian.container.ServerSetupObserver] (main) Setup task failed during setup. Offending class 'org.jboss.as.test.integration.security.loginmodules.LdapExtLDAPServerSetupTask at 5871a482': net.sf.ehcache.CacheException: Another unnamed CacheManager already exists in the same VM. Please provide unique names for each CacheManager in the config or do one of following:
> 1. Use one of the CacheManager.create() static factory methods to reuse same CacheManager with same name or create one if necessary
> 2. Shutdown the earlier cacheManager before creating new one with same name.
> The source of the existing CacheManager is: [Programmatically configured]
>         at net.sf.ehcache.CacheManager.assertNoCacheManagerExistsWithSameName(CacheManager.java:628)
>         at net.sf.ehcache.CacheManager.init(CacheManager.java:392)
>         at net.sf.ehcache.CacheManager.<init>(CacheManager.java:270)
>         at org.jboss.as.test.integration.ldap.InMemoryDirectoryServiceFactory.init(InMemoryDirectoryServiceFactory.java:119)
>         at org.apache.directory.server.core.factory.DSAnnotationProcessor.createDS(DSAnnotationProcessor.java:87)
>         at org.apache.directory.server.core.factory.DSAnnotationProcessor.getDirectoryService(DSAnnotationProcessor.java:318)
>         at org.jboss.as.test.integration.security.loginmodules.LdapExtLDAPServerSetupTask.createLdap2(LdapExtLDAPServerSetupTask.java:238)
>         at org.jboss.as.test.integration.security.loginmodules.LdapExtLDAPServerSetupTask.setup(LdapExtLDAPServerSetupTask.java:125)
>         at org.jboss.as.arquillian.container.ServerSetupObserver.handleBeforeDeployment(ServerSetupObserver.java:116)
>         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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
>         at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
>         at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>         at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:155)
>         at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
>         at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
>         at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
>         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  Wed Dec  6 11:20:57 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:57 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5233) Optimize marshalled size of
	web sessions
In-Reply-To: <JIRA.12583160.1440775095000@Atlassian.JIRA>
References: <JIRA.12583160.1440775095000@Atlassian.JIRA>
	<JIRA.12583160.1440775095000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583160.1440775095000.88206.1512577257527@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5233.
----------------------------


> Optimize marshalled size of web sessions
> ----------------------------------------
>
>                 Key: WFLY-5233
>                 URL: https://issues.jboss.org/browse/WFLY-5233
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>
> There are a couple of marshalling optimizations that we can make in the current web session clustering code:
> * We currently marshal session identifiers as UTF-8 strings.  For the default session id length, this result in 42 bytes for each cache key.  Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
> * We currently store the metadata of a session in a single cache entry.  The metadata is composed of:
> *# Creation timestamp (long)
> *# Last access timestamp (long)
> *# Max inactive interval (int)
> #1 is static.  #2 updates every request. #3 is "effectively" static.  If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated for a read-only request.  Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long.  Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.



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

From issues at jboss.org  Wed Dec  6 11:20:57 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:57 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4361) Remove usages of
 jboss-common-core from the EJB subsystem and libraries
In-Reply-To: <JIRA.12563536.1424276113000@Atlassian.JIRA>
References: <JIRA.12563536.1424276113000@Atlassian.JIRA>
	<JIRA.12563536.1424276113000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12563536.1424276113000.88210.1512577257708@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4361.
----------------------------


> Remove usages of jboss-common-core from the EJB subsystem and libraries
> -----------------------------------------------------------------------
>
>                 Key: WFLY-4361
>                 URL: https://issues.jboss.org/browse/WFLY-4361
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: EJB
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Alpha1
>
>




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

From issues at jboss.org  Wed Dec  6 11:20:57 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:57 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5206) Intermittent NPE when
 invoking method requestDestroyed
In-Reply-To: <JIRA.12582623.1440579419000@Atlassian.JIRA>
References: <JIRA.12582623.1440579419000@Atlassian.JIRA>
	<JIRA.12582623.1440579419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582623.1440579419000.88215.1512577257994@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5206.
----------------------------


> Intermittent NPE when invoking method requestDestroyed
> ------------------------------------------------------
>
>                 Key: WFLY-5206
>                 URL: https://issues.jboss.org/browse/WFLY-5206
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>
> Setup: 4-node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> This error was seen during clustering failover testing in the following scenario:
> ejb-ejbservlet-repl-sync (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with synchronously replicated cache)
> After undeploying application on perf19 (second node in the cluster), NullPointerException was logged 31 times in the server log.
> Stacktrace:
> {code}
> 2015/08/18 20:01:40:973 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Going to undeploy: 'clusterbench-ee7.ear' from 'perf19' now.
> 2015/08/18 20:01:41:265 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Requesting: {
>     "operation" : "undeploy",
>     "address" : [{
>         "deployment" : "clusterbench-ee7.ear"
>     }]
> }
> 20:01:41,706 INFO  [org.xnio] (RMI TCP Connection(14)-10.16.90.52) XNIO version 3.3.1.Final
> 20:01:41,918 INFO  [org.xnio.nio] (RMI TCP Connection(14)-10.16.90.52) XNIO NIO Implementation Version 3.3.1.Final
> 20:01:41,969 INFO  [org.jboss.remoting] (RMI TCP Connection(14)-10.16.90.52) JBoss Remoting version 4.0.9.Final
> [JBossINF] [0m[0m20:01:42,603 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 79) WFLYUT0022: Unregistered web context: /clusterbench
> [JBossINF] [0m[0m20:01:42,603 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0022: Unregistered web context: /clusterbench-passivating
> [JBossINF] [0m[0m20:01:42,679 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 78) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m20:01:42,679 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[31m20:01:42,681 ERROR [io.undertow.servlet.request] (default task-46) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.NullPointerException
> [JBossINF] 	at org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:135)
> [JBossINF] 	at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:325)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbservlet-undeploy-repl-sync/5/console-perf19/
> We also see the very same error in the scenario where the nodes shutdown instead of undeploying application - right after the server shutdown has been requested (we do not use graceful shutdown yet).
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbservlet-shutdown-repl-async/6/console-perf18/
> May be relevant to https://issues.jboss.org/browse/JBEAP-863 as both errors come together, under the same conditions.



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

From issues at jboss.org  Wed Dec  6 11:20:58 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:58 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4696) OutOfMemory DirectByteBuffer
	XNIO
In-Reply-To: <JIRA.12573142.1432824677000@Atlassian.JIRA>
References: <JIRA.12573142.1432824677000@Atlassian.JIRA>
	<JIRA.12573142.1432824677000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573142.1432824677000.88224.1512577258435@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4696.
----------------------------


> OutOfMemory DirectByteBuffer XNIO
> ---------------------------------
>
>                 Key: WFLY-4696
>                 URL: https://issues.jboss.org/browse/WFLY-4696
>             Project: WildFly
>          Issue Type: Bug
>          Components: IO, Web (Undertow)
>    Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Final
>            Reporter: Carlos Rodr?guez Aguado
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 10.0.0.CR1
>
>         Attachments: wfly9_0_0_final.mp4, wlfy.mp4
>
>
> I get this errors constantly in my server when a web connection is interrupted from the browser for instance:
> 11:50:45,301 ERROR [stderr] (default task-339) Exception in thread "default task-339" java.nio.BufferOverflowException
> 11:50:45,301 ERROR [stderr] (default task-339) 	at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> 11:50:45,301 ERROR [stderr] (default task-339) 	at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> 11:50:45,301 ERROR [stderr] (default task-339) 	at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> 11:50:45,301 ERROR [stderr] (default task-339) 	at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:150)
> 11:50:45,301 ERROR [stderr] (default task-339) 	at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpResponseConduit.java:629)
> 11:50:45,301 ERROR [stderr] (default task-339) 	at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:205)
> 11:50:45,301 ERROR [stderr] (default task-339) 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 11:50:45,301 ERROR [stderr] (default task-339) 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 11:50:45,301 ERROR [stderr] (default task-339) 	at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> 11:50:45,317 ERROR [stderr] (default task-339) 	at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> 11:50:45,317 ERROR [stderr] (default task-339) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:201)
> 11:50:45,317 ERROR [stderr] (default task-339) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> 11:50:45,317 ERROR [stderr] (default task-339) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:50:45,317 ERROR [stderr] (default task-339) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:50:45,317 ERROR [stderr] (default task-339) 	at java.lang.Thread.run(Thread.java:745)
> And then, I think this errors lead to a OutOfMemory crash:
> 14:23:09,592 ERROR [org.xnio.listener] (default I/O-3) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> 	at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> 	at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> 	at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> 	at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:143) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> This is the trace for version 8.2 of WildFly:
> 17:17:16,957 ERROR [io.undertow.request] (default task-49) Undertow request failed HttpServerExchange{ GET /modulab/servlet/ShowPDFReportServlet}: java.nio.BufferOverflowException
> 	at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363) [rt.jar:1.8.0_20]
> 	at java.nio.ByteBuffer.put(ByteBuffer.java:859) [rt.jar:1.8.0_20]
> 	at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> 	at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:166)
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:564)
> 	at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:106)
> 	at org.xnio.conduits.Conduits.writeFinalBasic(Conduits.java:132) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.writeFinal(AbstractFixedLengthStreamSinkConduit.java:175)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:194)
> 	at io.undertow.server.HttpServerExchange$WriteDispatchChannel.writeFinal(HttpServerExchange.java:1829)
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:565)
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:497)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:581)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:308)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> 10:57:12,389 ERROR [org.xnio.listener] (default I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> 	at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> 	at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> 	at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> 	at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:146) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.3.0.Final.jar:3.3.0.Final]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.3.0.Final.jar:3.3.0.Final]



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


From issues at jboss.org  Wed Dec  6 11:20:58 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:58 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5105) [Migration operation]
 Attribute discovery-group in cluster-connection is not migrated
In-Reply-To: <JIRA.12581228.1439561133000@Atlassian.JIRA>
References: <JIRA.12581228.1439561133000@Atlassian.JIRA>
	<JIRA.12581228.1439561133000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581228.1439561133000.88229.1512577258709@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5105.
----------------------------


> [Migration operation] Attribute discovery-group in cluster-connection is not migrated
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-5105
>                 URL: https://issues.jboss.org/browse/WFLY-5105
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Critical
>             Fix For: 10.0.0.Beta2
>
>
> Attribute discovery-group-ref in cluster-connection is not migrated. For example:
> {code}
>             <cluster-connection name="cc3">
>                 <address>cc3-address</address>
>                 <connector-ref>netty</connector-ref>
>                 <discovery-group-ref discovery-group-name="groupC"/>
>             </cluster-connection>
> {code}
> migrates as:
> {code}
> <cluster-connection name="cc3" connector-name="netty" address="cc3-address"/>
> {code}
> I'm setting higher priority as discovery group is by default in configuration in EAP 6.



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

From issues at jboss.org  Wed Dec  6 11:20:59 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:59 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5202) Decouple cluster name from
	name of channel
In-Reply-To: <JIRA.12582592.1440531225000@Atlassian.JIRA>
References: <JIRA.12582592.1440531225000@Atlassian.JIRA>
	<JIRA.12582592.1440531225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582592.1440531225000.88235.1512577259022@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5202.
----------------------------


> Decouple cluster name from name of channel
> ------------------------------------------
>
>                 Key: WFLY-5202
>                 URL: https://issues.jboss.org/browse/WFLY-5202
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>
> Currently, JGroups channels are connected using their name as the cluster name.  However, the name of a channel cannot be defined as an expression - which limits the ability to parameterize a given server configuration.  This can improved by adding an optional "cluster" attribute (which would default to the channel name) that supports expressions.



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

From issues at jboss.org  Wed Dec  6 11:20:59 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:59 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4845) jboss-client.jar use jms 2.0
 specification from geronimo-jms
In-Reply-To: <JIRA.12576598.1435671534000@Atlassian.JIRA>
References: <JIRA.12576598.1435671534000@Atlassian.JIRA>
	<JIRA.12576598.1435671534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576598.1435671534000.88241.1512577259389@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4845.
----------------------------


> jboss-client.jar use jms 2.0 specification from geronimo-jms
> ------------------------------------------------------------
>
>                 Key: WFLY-4845
>                 URL: https://issues.jboss.org/browse/WFLY-4845
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Martin Styk
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> jboss-client.jar uses jms 2.0 specification from geronimo-jms_2.0_spec not from jboss-jms-api_2.0_spec. As EAP 7.0.0.DR5 uses jboss specs, we should use it in the client jar as well.
> There is also issue in geronimo-jms_2.0_spec : 
> public @interface JMSDestinationDefinitions {
>     public JMSConnectionFactoryDefinition[] value();
> }
> This should contain public JMSDestinationDefinition[] value(); instead of  public JMSConnectionFactoryDefinition[] value();



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

From issues at jboss.org  Wed Dec  6 11:20:59 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:20:59 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5113) [Migration operation] [Web to
 Undertow] Migration fails with java.lang.NoClassDefFoundError
In-Reply-To: <JIRA.12581549.1439810506000@Atlassian.JIRA>
References: <JIRA.12581549.1439810506000@Atlassian.JIRA>
	<JIRA.12581549.1439810506000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581549.1439810506000.88245.1512577259660@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5113.
----------------------------


> [Migration operation] [Web to Undertow] Migration fails with java.lang.NoClassDefFoundError
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5113
>                 URL: https://issues.jboss.org/browse/WFLY-5113
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 10.0.0.Beta2
>
>
> Unable to migrate web subsystem due java.lang.NoClassDefFoundError [1]
> [1]
> {noformat}
> 13:01:52,134 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("migrate") failed - address: ([("subsystem" => "web")]): java.lang.NoClassDefFoundError: org/wildfly/extension/undertow/UndertowExtension
> 	at org.jboss.as.web.WebMigrateOperation.migrateVirtualHost(WebMigrateOperation.java:572)
> 	at org.jboss.as.web.WebMigrateOperation.transformResources(WebMigrateOperation.java:493)
> 	at org.jboss.as.web.WebMigrateOperation.access$300(WebMigrateOperation.java:109)
> 	at org.jboss.as.web.WebMigrateOperation$2.execute(WebMigrateOperation.java:180)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:846) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:637) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1272) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:394) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:225) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_45]
> 	at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_45]
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:147) [wildfly-controller-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298) [wildfly-protocol-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-2.0.0.Beta1.jar:2.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> Caused by: java.lang.ClassNotFoundException: org.wildfly.extension.undertow.UndertowExtension from [Module "org.jboss.as.web:main" from local module loader @2f333739 (finder: local module finder @77468bd9 (roots: /home/rhatlapa/projects/redhat_projects/migration/jboss-eap-7.0/modules,/home/rhatlapa/projects/redhat_projects/migration/jboss-eap-7.0/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.4.3.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455) [jboss-modules.jar:1.4.3.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404) [jboss-modules.jar:1.4.3.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385) [jboss-modules.jar:1.4.3.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130) [jboss-modules.jar:1.4.3.Final]
> 	... 24 more
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:21:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4792) Undertow deployment-level
 session statistics not available for distributable webapp
In-Reply-To: <JIRA.12575181.1434467686000@Atlassian.JIRA>
References: <JIRA.12575181.1434467686000@Atlassian.JIRA>
	<JIRA.12575181.1434467686000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575181.1434467686000.88252.1512577260031@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4792.
----------------------------


> Undertow deployment-level session statistics not available for distributable webapp
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-4792
>                 URL: https://issues.jboss.org/browse/WFLY-4792
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 9.0.0.CR2
>            Reporter: Martin Kouba
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta1
>
>
> {{org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager}} which is used by default even for non-HA configurations in WildFly 9.0.0.CR2 (e.g. {{standalone.xml}} in app server distribution) does not implement {{io.undertow.server.session.SessionManagerStatistics}} and so no stats except for {{activeSessions}} are available. 



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

From issues at jboss.org  Wed Dec  6 11:21:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4836) Restore SOAP-over-JMS
 integration after HornetQ replacement with Apache Active Artemis
In-Reply-To: <JIRA.12576395.1435323012000@Atlassian.JIRA>
References: <JIRA.12576395.1435323012000@Atlassian.JIRA>
	<JIRA.12576395.1435323012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576395.1435323012000.88257.1512577260358@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4836.
----------------------------


> Restore SOAP-over-JMS integration after HornetQ replacement with Apache Active Artemis
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-4836
>                 URL: https://issues.jboss.org/browse/WFLY-4836
>             Project: WildFly
>          Issue Type: Task
>          Components: Web Services
>    Affects Versions: 10.0.0.Alpha3
>            Reporter: Jeff Mesnil
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Alpha5
>
>
> WildFly 10 replaces HornetQ with Apache Active Artemis.
> Most HornetQ runtime will be removed from WildFly dependencies.
> This is handled by WFLY-4592 except for the dependencies in org.wildfly:wildfly-webservices-tests-integration that depends on org.hornetq:* artifacts. 
> These dependencies should be inspected and replaced by their corresponding org.apache.activemq.artemis:* arteficts that provides the messaging runtime for WildFly 10.



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

From issues at jboss.org  Wed Dec  6 11:21:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4584) Use Apache ActiveMQ Artemis
 as the messaging broker
In-Reply-To: <JIRA.12570688.1430815736000@Atlassian.JIRA>
References: <JIRA.12570688.1430815736000@Atlassian.JIRA>
	<JIRA.12570688.1430815736000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570688.1430815736000.88267.1512577260778@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4584.
----------------------------


> Use Apache ActiveMQ Artemis as the messaging broker
> ---------------------------------------------------
>
>                 Key: WFLY-4584
>                 URL: https://issues.jboss.org/browse/WFLY-4584
>             Project: WildFly
>          Issue Type: Task
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha4
>
>
> replace the current messaging subsystem (with HornetQ) with a new messaging-activemq subsystem (with ActiveMQ Artemis)



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

From issues at jboss.org  Wed Dec  6 11:21:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4568) Remove support for
 jboss-as-resource-adapters_1_0.xsd
In-Reply-To: <JIRA.12570082.1430225699000@Atlassian.JIRA>
References: <JIRA.12570082.1430225699000@Atlassian.JIRA>
	<JIRA.12570082.1430225699000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570082.1430225699000.88271.1512577261047@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4568.
----------------------------


> Remove support for jboss-as-resource-adapters_1_0.xsd
> -----------------------------------------------------
>
>                 Key: WFLY-4568
>                 URL: https://issues.jboss.org/browse/WFLY-4568
>             Project: WildFly
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Alpha5
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3095) Weld subsystem exposes way
 too much dependancies to user deployment
In-Reply-To: <JIRA.12534548.1394459414000@Atlassian.JIRA>
References: <JIRA.12534548.1394459414000@Atlassian.JIRA>
	<JIRA.12534548.1394459414000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534548.1394459414000.88279.1512577261500@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3095.
----------------------------


> Weld subsystem exposes way too much dependancies to user deployment
> -------------------------------------------------------------------
>
>                 Key: WFLY-3095
>                 URL: https://issues.jboss.org/browse/WFLY-3095
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Final
>            Reporter: Tomaz Cerar
>            Assignee: Jozef Hartinger
>            Priority: Critical
>             Fix For: 10.0.0.Alpha2
>
>
> module org.jboss.as.weld should not be added as dependency to user deployment.
> It has way too much dependencies and some of them export their dependencies which than end up in user deployment.
> We should probably have extra module for stuff that is exposed to deployment.
> Also lots of dependencies that weld subsystem has should be optional as we shouldn't be required to have dependency to almost every single subsystem we have as required.



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

From issues at jboss.org  Wed Dec  6 11:21:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4810)
 FormAuthenticationWebFailoverTestCase(SYNC-tcp) fails frequently
In-Reply-To: <JIRA.12575663.1434711105000@Atlassian.JIRA>
References: <JIRA.12575663.1434711105000@Atlassian.JIRA>
	<JIRA.12575663.1434711105000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575663.1434711105000.88286.1512577261801@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4810.
----------------------------


> FormAuthenticationWebFailoverTestCase(SYNC-tcp) fails frequently
> ----------------------------------------------------------------
>
>                 Key: WFLY-4810
>                 URL: https://issues.jboss.org/browse/WFLY-4810
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Stuart Douglas
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Alpha4
>
>
> Seems to have been introduced by https://github.com/wildfly/wildfly/pull/7507



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

From issues at jboss.org  Wed Dec  6 11:21:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4736) UndertowDeploymentService
 starts web components in MSC thread
In-Reply-To: <JIRA.12573730.1433338485000@Atlassian.JIRA>
References: <JIRA.12573730.1433338485000@Atlassian.JIRA>
	<JIRA.12573730.1433338485000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573730.1433338485000.88290.1512577262093@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4736.
----------------------------


> UndertowDeploymentService starts web components in MSC thread
> -------------------------------------------------------------
>
>                 Key: WFLY-4736
>                 URL: https://issues.jboss.org/browse/WFLY-4736
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.0.CR1
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> The UndertowDeploymentService triggers web components' start and stop lifecycle within the MSC thread which can lead to the server blocking during deployment. This was an issue with the older JBoss Web version of the Service too which was fixed as part of https://issues.jboss.org/browse/AS7-5969 (https://github.com/wildfly/wildfly/pull/3455). The same needs to be ported to this UndertowDeploymentService.
> Here's an example where a user deployment ends up being blocked https://developer.jboss.org/message/932681#932681



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

From issues at jboss.org  Wed Dec  6 11:21:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5086) [Migration operation] HA
 configuration is not migrated
In-Reply-To: <JIRA.12580960.1439376589000@Atlassian.JIRA>
References: <JIRA.12580960.1439376589000@Atlassian.JIRA>
	<JIRA.12580960.1439376589000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580960.1439376589000.88295.1512577262446@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5086.
----------------------------


> [Migration operation] HA configuration is not migrated
> ------------------------------------------------------
>
>                 Key: WFLY-5086
>                 URL: https://issues.jboss.org/browse/WFLY-5086
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> HA configuration is not migrated.
> For example:
> {code}
>                 <shared-store>true</shared-store>
> {code}
> does not have equivalent config in in migrated configuration.
> Customer with HA configuration for HornetQ will not have this configuration after migration.



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

From issues at jboss.org  Wed Dec  6 11:21:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4986) LazyValidatorFactoryTestCase
 fails on IBM jdk
In-Reply-To: <JIRA.12578870.1437560878000@Atlassian.JIRA>
References: <JIRA.12578870.1437560878000@Atlassian.JIRA>
	<JIRA.12578870.1437560878000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578870.1437560878000.88302.1512577262896@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4986.
----------------------------


> LazyValidatorFactoryTestCase fails on IBM jdk
> ---------------------------------------------
>
>                 Key: WFLY-4986
>                 URL: https://issues.jboss.org/browse/WFLY-4986
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, Test Suite
>    Affects Versions: 10.0.0.Alpha5
>         Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480-20150129_02)
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150116_231420 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_GA_20150116_2030_B231420
> JIT  - tr.r14.java_20150109_82886.02
> GC   - R28_Java8_GA_20150116_2030_B231420_CMPRSS
> J9CL - 20150116_231420)
> JCL - 20150123_01 based on Oracle jdk8u31-b12
>            Reporter: Petr Kremensky
>            Assignee: Hardy Ferentschik
>             Fix For: 10.0.0.Beta1
>
>
> org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase#testSpecificProviderCanBeConfiguredInValidationXml fails with IBM JDK8
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.09 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase)  Time elapsed: 0.012 sec  <<< ERROR!
> javax.validation.ValidationException: HV000123: Unable to parse META-INF/validation.xml.
> 	at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:181)
> 	at java.io.BufferedInputStream.reset(BufferedInputStream.java:457)
> 	at org.hibernate.validator.internal.xml.XmlParserHelper.getSchemaVersion(XmlParserHelper.java:109)
> 	at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:79)
> 	at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:287)
> 	at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:361)
> 	at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:214)
> 	at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> 	at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> 	at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> 	at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:21:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5294) Upgrade HAL to 2.8.8.Final
In-Reply-To: <JIRA.12584219.1441708288000@Atlassian.JIRA>
References: <JIRA.12584219.1441708288000@Atlassian.JIRA>
	<JIRA.12584219.1441708288000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584219.1441708288000.88317.1512577263818@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5294.
----------------------------


> Upgrade HAL to 2.8.8.Final
> --------------------------
>
>                 Key: WFLY-5294
>                 URL: https://issues.jboss.org/browse/WFLY-5294
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Tomas Hofman
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5330) Can't start managed domain in
 --admin-only with EAP 6.4 configuration
In-Reply-To: <JIRA.12584771.1442216061000@Atlassian.JIRA>
References: <JIRA.12584771.1442216061000@Atlassian.JIRA>
	<JIRA.12584771.1442216061000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584771.1442216061000.88322.1512577263988@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5330.
----------------------------


> Can't start managed domain in --admin-only with EAP 6.4 configuration
> ---------------------------------------------------------------------
>
>                 Key: WFLY-5330
>                 URL: https://issues.jboss.org/browse/WFLY-5330
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ladislav Thon
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> When starting WildFly 10.0.0.Beta2 managed domain in {{--admin-only}} mode to perform {{:migrate}} operations on old subsystems \[1\], using an unmodified {{domain.xml}} and {{host.xml}} configuration files from EAP 6.4.0, I'm getting errors \[2\].
> Apparently, the domain configuration files in EAP 6.4 still contain the {{configadmin}} extension and subsystems. The standalone configuration files from EAP 6.4 no longer contain that, which is why this problem wasn't found earlier and wasn't described in WFLY-5092.
> Based on http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004306.html, I'm expecting that I don't have to perform any changes to the EAP 6.4 configuration files.
> \[1\]
> {code}
> unzip jboss-eap-6.4.0.zip
> unzip wildfly-10.0.0.Beta2.zip
> rm wildfly-10.0.0.Beta2/domain/configuration/*.xml
> cp jboss-eap-6.4/domain/configuration/domain.xml wildfly-10.0.0.Beta2/domain/configuration/
> cp jboss-eap-6.4/domain/configuration/host.xml wildfly-10.0.0.Beta2/domain/configuration/
> ./wildfly-10.0.0.Beta2/bin/domain.sh --admin-only
> {code}
> \[2\]
> {code}
> [Host Controller] 09:21:47,835 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> [Host Controller] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> [Host Controller] 	at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:673)
> [Host Controller] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:272)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.jboss.as.configadmin
> [Host Controller] 	at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:155)
> [Host Controller] 	at org.jboss.as.host.controller.parsing.DomainXml_Legacy.readDomainElement2_0(DomainXml_Legacy.java:377)
> [Host Controller] 	at org.jboss.as.host.controller.parsing.DomainXml_Legacy.readElement(DomainXml_Legacy.java:133)
> [Host Controller] 	...
> {code}



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

From issues at jboss.org  Wed Dec  6 11:21:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5251) Upgrade JBossWS from
 5.1.0.Beta1 to 5.1.0.Final
In-Reply-To: <JIRA.12583398.1441095259000@Atlassian.JIRA>
References: <JIRA.12583398.1441095259000@Atlassian.JIRA>
	<JIRA.12583398.1441095259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583398.1441095259000.88326.1512577264167@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5251.
----------------------------


> Upgrade JBossWS from 5.1.0.Beta1 to 5.1.0.Final
> -----------------------------------------------
>
>                 Key: WFLY-5251
>                 URL: https://issues.jboss.org/browse/WFLY-5251
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4006) Java EE 7 with all BOM lacks
 JAX-RS 2.0 API dependency
In-Reply-To: <JIRA.12555770.1413976131000@Atlassian.JIRA>
References: <JIRA.12555770.1413976131000@Atlassian.JIRA>
	<JIRA.12555770.1413976131000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555770.1413976131000.88331.1512577264360@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4006.
----------------------------


> Java EE 7 with all BOM lacks JAX-RS 2.0 API dependency
> ------------------------------------------------------
>
>                 Key: WFLY-4006
>                 URL: https://issues.jboss.org/browse/WFLY-4006
>             Project: WildFly
>          Issue Type: Enhancement
>    Affects Versions: 8.1.0.Final
>            Reporter: Vineet Reynolds
>            Assignee: Tomaz Cerar
>            Priority: Optional
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> Adding the {{org.wildfly.bom:jboss-javaee-7.0-with-all}} BOM to a Maven project does not pull in the {{org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec}} dependency.
> Hence, users of this BOM are required to add the JAX-RS 2.0 API, specifying the version explicitly, to consume the JAX-RS APIs in their projects.



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

From issues at jboss.org  Wed Dec  6 11:21:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5145) Jacorb subsystem does not
 contain operation "describe-migration"
In-Reply-To: <JIRA.12582000.1440076040000@Atlassian.JIRA>
References: <JIRA.12582000.1440076040000@Atlassian.JIRA>
	<JIRA.12582000.1440076040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582000.1440076040000.88336.1512577264847@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5145.
----------------------------


> Jacorb subsystem does not contain operation "describe-migration"
> ----------------------------------------------------------------
>
>                 Key: WFLY-5145
>                 URL: https://issues.jboss.org/browse/WFLY-5145
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> As part of the migrate functionality for moving from JacORB to IIOP OpenJDK the old subsystem should contain operation {{describe-migration}}
> {code}
> /subsystem=jacorb:describe-migration()
> {code}
> for user gets information about following steps.
> But JacORB subsystem does not contain any such operation
> {code}
> /subsystem=jacorb:read-operation-names()
> {
>     "outcome" => "success",
>     "result" => [
>         "add",
>         "list-add",
>         "list-clear",
>         "list-get",
>         "list-remove",
>         "map-clear",
>         "map-get",
>         "map-put",
>         "map-remove",
>         "migrate",
>         "query",
>         "read-attribute",
>         "read-attribute-group",
>         "read-attribute-group-names",
>         "read-children-names",
>         "read-children-resources",
>         "read-children-types",
>         "read-operation-description",
>         "read-operation-names",
>         "read-resource",
>         "read-resource-description",
>         "remove",
>         "undefine-attribute",
>         "whoami",
>         "write-attribute"
>     ]
> }
> {code}



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

From issues at jboss.org  Wed Dec  6 11:21:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5198) Clustering performance
	regression
In-Reply-To: <JIRA.12582518.1440501569000@Atlassian.JIRA>
References: <JIRA.12582518.1440501569000@Atlassian.JIRA>
	<JIRA.12582518.1440501569000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582518.1440501569000.88342.1512577265194@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5198.
----------------------------


> Clustering performance regression
> ---------------------------------
>
>                 Key: WFLY-5198
>                 URL: https://issues.jboss.org/browse/WFLY-5198
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 10.0.0.CR1
>
>
> Our clustering stress tests show huge performance drop of 7.0.0.DR8 bits compared to 6.4.0 bits.
> Compare these results:
> stress-heavyread-session-repl-sync
> 7.0.0.DR8: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-heavyread-session-repl-sync_noperf21/2/artifact/report/graph-throughput.png] + [response times|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-heavyread-session-repl-sync_noperf21/2/artifact/report/graph-reponse-times.png]
> 6.4.0.GA:  [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-heavyread-session-repl-sync_noperf21/1/artifact/report/graph-throughput.png] + [response times|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-heavyread-session-repl-sync_noperf21/1/artifact/report/graph-reponse-times.png]
> Jenkins runs (server configs + logs can be found here):
> 7.0.0.DR8: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-heavyread-session-repl-sync_noperf21/2/
> 6.4.0.GA: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-heavyread-session-repl-sync_noperf21/1/
> One can observe that when using 7.0.0.DR8 bits, throughput reaches a threshold of approximately 6000 TPS. This happens in each test using *REPL-SYNC* cache, for example:
> stress-session-repl-sync
> 7.0.0.DR8: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-session-repl-sync_noperf21/2/artifact/report/graph-throughput.png] + [response times|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-session-repl-sync_noperf21/2/artifact/report/graph-reponse-times.png]
> 6.4.0.GA:  [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-session-repl-sync_noperf21/1/artifact/report/graph-throughput.png] + [response times|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-session-repl-sync_noperf21/1/artifact/report/graph-reponse-times.png]
> All tests use a 4-node EAP cluster and 5 nodes that generate load. Adding another node to the EAP cluster, the threshold is lowered to 5200 TPS and the max. response time raises, see:
> stress-heavyread-session-repl-sync with 5-node cluster
> 7.0.0.DR8: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stress-heavyread-session-repl-sync_noperf21/1/artifact/report/graph-throughput.png] + [response times|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stress-heavyread-session-repl-sync_noperf21/1/artifact/report/graph-reponse-times.png]
> *Most of the other scenarios indicate performance regression as well*.
> stress-session-dist-sync
> 7.0.0.DR8: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-session-dist-sync_noperf21/1/artifact/report/graph-throughput.png] + [response times|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-session-dist-sync_noperf21/1/artifact/report/graph-reponse-times.png]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-session-dist-sync_noperf21/1/artifact/report/graph-throughput.png] + [response times|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-session-dist-sync_noperf21/1/artifact/report/graph-reponse-times.png]
> stress-session-repl-async
> 7.0.0.DR8: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-session-repl-async_noperf21/2/artifact/report/graph-throughput.png] + [response times|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-stress-session-repl-async_noperf21/2/artifact/report/graph-reponse-times.png]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-session-repl-async_noperf21/1/artifact/report/graph-throughput.png] + [response times|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-stress-session-repl-async_noperf21/1/artifact/report/graph-reponse-times.png]
> This issue is related to https://issues.jboss.org/browse/JBEAP-768



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

From issues at jboss.org  Wed Dec  6 11:21:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5165) Quickstart Arquillian tests
 log warning deprecated protocol warning
In-Reply-To: <JIRA.12582158.1440160547000@Atlassian.JIRA>
References: <JIRA.12582158.1440160547000@Atlassian.JIRA>
	<JIRA.12582158.1440160547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582158.1440160547000.88346.1512577265505@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5165.
----------------------------


> Quickstart Arquillian tests log warning deprecated protocol warning
> -------------------------------------------------------------------
>
>                 Key: WFLY-5165
>                 URL: https://issues.jboss.org/browse/WFLY-5165
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Sande Gilda
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.CR1
>
>
> A warning is logged during Arquillian tests for the JBoss EAP 7 quickstarts: :
> WARN: The protocol 'http-remoting-jmx' is deprecated, instead you should use 'remote+http'.
> This JIRA was created for the issue: https://issues.jboss.org/browse/JBEAP-579
> [~mjobanek] looked at this and commented in the JIRA:
> AFAIK, you are not able to get rid of this warning by any change of the arquillian configuration - this is caused by the wildfly-arquillian-container adapter itself.
> During a construction of the ProtocolMetadata [1], the adapter retrieves also JMX context and this retrieval [2] causes the warning.
> I've already noticed this behavior, however, I haven't time to investigate it deeper.
> Please, feell free to open a jira for this issue.
> [1] https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main/java/org/jboss/as/arquillian/container/ManagementClient.java#L181-L206
> [2] https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main/java/org/jboss/as/arquillian/container/ManagementClient.java#L370



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

From issues at jboss.org  Wed Dec  6 11:21:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5116) Removal of the ANTLR version
	3.4 module
In-Reply-To: <JIRA.12581613.1439829778000@Atlassian.JIRA>
References: <JIRA.12581613.1439829778000@Atlassian.JIRA>
	<JIRA.12581613.1439829778000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581613.1439829778000.88349.1512577265690@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5116.
----------------------------


> Removal of the ANTLR version 3.4 module
> ---------------------------------------
>
>                 Key: WFLY-5116
>                 URL: https://issues.jboss.org/browse/WFLY-5116
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Build System
>            Reporter: Sanne Grinovero
>            Assignee: Sanne Grinovero
>             Fix For: 10.0.0.Beta2
>
>
> The module of version 3.4 of ANTLR is no longer needed, this was being used by the Infinispan Query component which has been removed with WFLY-4695.
> Hibernate ORM still uses the goold old ANTLR 2.7.x



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

From issues at jboss.org  Wed Dec  6 11:21:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4904) DuplicateServiceException for
	datasources
In-Reply-To: <JIRA.12577719.1436543365000@Atlassian.JIRA>
References: <JIRA.12577719.1436543365000@Atlassian.JIRA>
	<JIRA.12577719.1436543365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577719.1436543365000.88358.1512577266426@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4904.
----------------------------


> DuplicateServiceException for datasources
> -----------------------------------------
>
>                 Key: WFLY-4904
>                 URL: https://issues.jboss.org/browse/WFLY-4904
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Jesper Pedersen
>            Assignee: Eduardo Martins
>            Priority: Blocker
>             Fix For: 10.0.0.Beta1
>
>
> {noformat}
> 2015-07-10 01:30:56,916 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-3) WFLYEJB0473: JNDI bindings for session bean named 'DataSourceBean' in deployment unit 'deployment "ejblite_packaging_war_datasource_singleton_ejblitejsp_vehicle_web.war"' are as follows:
> 	java:global/ejblite_packaging_war_datasource_singleton_ejblitejsp_vehicle_web/DataSourceBean!com.sun.ts.tests.ejb30.lite.packaging.war.datasource.common.DataSourceIF
> 	java:app/ejblite_packaging_war_datasource_singleton_ejblitejsp_vehicle_web/DataSourceBean!com.sun.ts.tests.ejb30.lite.packaging.war.datasource.common.DataSourceIF
> 	java:module/DataSourceBean!com.sun.ts.tests.ejb30.lite.packaging.war.datasource.common.DataSourceIF
> 	java:global/ejblite_packaging_war_datasource_singleton_ejblitejsp_vehicle_web/DataSourceBean
> 	java:app/ejblite_packaging_war_datasource_singleton_ejblitejsp_vehicle_web/DataSourceBean
> 	java:module/DataSourceBean
> 2015-07-10 01:30:56,949 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ejblite_packaging_war_datasource_singleton_ejblitejsp_vehicle_web.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejblite_packaging_war_datasource_singleton_ejblitejsp_vehicle_web.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "ejblite_packaging_war_datasource_singleton_ejblitejsp_vehicle_web.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-2.0.0.Alpha6.jar:2.0.0.Alpha6]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source.java:comp/env/compds2 is already registered
> 	at org.jboss.as.connector.deployers.datasource.DataSourceDefinitionInjectionSource.getResourceValue(DataSourceDefinitionInjectionSource.java:175)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:211)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:182)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:186)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:143)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-2.0.0.Alpha6.jar:2.0.0.Alpha6]
> 	... 5 more
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source.java:comp/env/compds2 is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> 	at org.jboss.as.connector.deployers.datasource.DataSourceDefinitionInjectionSource.startDataSource(DataSourceDefinitionInjectionSource.java:274)
> 	at org.jboss.as.connector.deployers.datasource.DataSourceDefinitionInjectionSource.getResourceValue(DataSourceDefinitionInjectionSource.java:171)
> 	... 11 more
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:21:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2137) transaction services do not
 start with jts enabled
In-Reply-To: <JIRA.12501331.1379963766000@Atlassian.JIRA>
References: <JIRA.12501331.1379963766000@Atlassian.JIRA>
	<JIRA.12501331.1379963766000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501331.1379963766000.88370.1512577266966@Atlassian.JIRA>


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

Kabir Khan closed WFLY-2137.
----------------------------


> transaction services do not start with jts enabled
> --------------------------------------------------
>
>                 Key: WFLY-2137
>                 URL: https://issues.jboss.org/browse/WFLY-2137
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Micha? Zegan
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Beta2
>
>         Attachments: standalone.xml
>
>
> When launching the app server in domain mode when there is a transaction subsystem active with jts set to true, server shows an error that there's a circular dependency between services.
> I don't have any log to show this but it is easily reproducible.



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


From issues at jboss.org  Wed Dec  6 11:21:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4377) Add support for Infinispan
 partition handling
In-Reply-To: <JIRA.12563848.1424566700000@Atlassian.JIRA>
References: <JIRA.12563848.1424566700000@Atlassian.JIRA>
	<JIRA.12563848.1424566700000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12563848.1424566700000.88376.1512577267408@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4377.
----------------------------


> Add support for Infinispan partition handling
> ---------------------------------------------
>
>                 Key: WFLY-4377
>                 URL: https://issues.jboss.org/browse/WFLY-4377
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta1
>
>
> Only applies to DIST mode.
> Add management operations to get and set the AvailabilityMode of a cache.



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

From issues at jboss.org  Wed Dec  6 11:21:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5065) Build fails with the IBM J9
	java compiler
In-Reply-To: <JIRA.12580473.1438854459000@Atlassian.JIRA>
References: <JIRA.12580473.1438854459000@Atlassian.JIRA>
	<JIRA.12580473.1438854459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580473.1438854459000.88420.1512577270878@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5065.
----------------------------


> Build fails with the IBM J9 java compiler
> -----------------------------------------
>
>                 Key: WFLY-5065
>                 URL: https://issues.jboss.org/browse/WFLY-5065
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Michael Musgrove
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Beta1
>
>
> I am getting an error from the maven enforcer plugin when building with the IBM J9 java compiler (J9VM - R28_Java8_SR1_20150410_1531_B243669):
>  
> [INFO] --- maven-enforcer-plugin:1.4:enforce (ban-transitive-deps) @ wildfly-feature-pack ---
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with message:
> org.wildfly:wildfly-feature-pack:pom:10.0.0.Beta1-SNAPSHOT
>    org.apache.cxf:cxf-rt-security-saml:jar:3.1.2:compile has transitive dependencies:
>       xalan:xalan:jar:2.7.1.jbossorg-1:compile
>          xalan:serializer:jar:2.7.1.jbossorg-1:compile



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

From issues at jboss.org  Wed Dec  6 11:21:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4911) Allow expressions for the
 "alias"-attribute of undertow's host configuration
In-Reply-To: <JIRA.12577818.1436786513000@Atlassian.JIRA>
References: <JIRA.12577818.1436786513000@Atlassian.JIRA>
	<JIRA.12577818.1436786513000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577818.1436786513000.88425.1512577271181@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4911.
----------------------------


> Allow expressions for the "alias"-attribute of undertow's host configuration
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-4911
>                 URL: https://issues.jboss.org/browse/WFLY-4911
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final, 9.0.0.Final
>            Reporter: Kostyantyn Zagorodniy
>            Assignee: Tomaz Cerar
>            Priority: Trivial
>              Labels: expression, system_properties, undertow, virtualhosts
>             Fix For: 10.0.0.Alpha6
>
>
> See description on Stackoverflow:
> http://stackoverflow.com/questions/31290907



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

From issues at jboss.org  Wed Dec  6 11:21:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4903) Add datasource transformers
 for target model version 1.3.0 (EAP 6.3)
In-Reply-To: <JIRA.12577713.1436540650000@Atlassian.JIRA>
References: <JIRA.12577713.1436540650000@Atlassian.JIRA>
	<JIRA.12577713.1436540650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577713.1436540650000.88431.1512577271611@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4903.
----------------------------


> Add datasource transformers for target model version 1.3.0 (EAP 6.3)
> --------------------------------------------------------------------
>
>                 Key: WFLY-4903
>                 URL: https://issues.jboss.org/browse/WFLY-4903
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Tomaz Cerar
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.CR1
>
>
> Datasource transformers are missing transformers for 1.3 version that is part of EAP 6.3 and 6.4



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

From issues at jboss.org  Wed Dec  6 11:21:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4635) @TransactionAttribute ignored
 on non-public SFSB PostActivate and PrePassivate lifecycle callbacks
In-Reply-To: <JIRA.12571710.1431607625000@Atlassian.JIRA>
References: <JIRA.12571710.1431607625000@Atlassian.JIRA>
	<JIRA.12571710.1431607625000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571710.1431607625000.88435.1512577272096@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4635.
----------------------------


> @TransactionAttribute ignored on non-public SFSB PostActivate and PrePassivate lifecycle callbacks
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4635
>                 URL: https://issues.jboss.org/browse/WFLY-4635
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.CR1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 10.0.0.Alpha3
>
>
> Non-public PostActivate and PrePassivate SFSB are not supposed to be lifecycle methods by WFLY-4127 which leads to a situation where transactional attributes on them are ignored. Public methods work as expected.



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

From issues at jboss.org  Wed Dec  6 11:21:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5203) mod_cluster read-resource can
 result in NPE if service is not started yet
In-Reply-To: <JIRA.12582605.1440547804000@Atlassian.JIRA>
References: <JIRA.12582605.1440547804000@Atlassian.JIRA>
	<JIRA.12582605.1440547804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582605.1440547804000.88439.1512577272382@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5203.
----------------------------


> mod_cluster read-resource can result in NPE if service is not started yet
> -------------------------------------------------------------------------
>
>                 Key: WFLY-5203
>                 URL: https://issues.jboss.org/browse/WFLY-5203
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5287) Synchronize Infinispan
 state-transfer chunk-size with the new upstream default
In-Reply-To: <JIRA.12584135.1441625445000@Atlassian.JIRA>
References: <JIRA.12584135.1441625445000@Atlassian.JIRA>
	<JIRA.12584135.1441625445000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584135.1441625445000.88443.1512577272728@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5287.
----------------------------


> Synchronize Infinispan state-transfer chunk-size with the new upstream default
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-5287
>                 URL: https://issues.jboss.org/browse/WFLY-5287
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>              Labels: clustering_performance
>             Fix For: 10.0.0.CR1
>
>
> Default value changed from 10.000 to 512:
> https://issues.jboss.org/browse/ISPN-4160?focusedCommentId=12956885&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12956885



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

From issues at jboss.org  Wed Dec  6 11:21:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4847) STOMP logging does not work
In-Reply-To: <JIRA.12576647.1435683840000@Atlassian.JIRA>
References: <JIRA.12576647.1435683840000@Atlassian.JIRA>
	<JIRA.12576647.1435683840000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576647.1435683840000.88447.1512577273024@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4847.
----------------------------


> STOMP logging does not work
> ---------------------------
>
>                 Key: WFLY-4847
>                 URL: https://issues.jboss.org/browse/WFLY-4847
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.0.CR2
>            Reporter: Ville Skytt?
>            Assignee: Jason Greene
>             Fix For: 9.0.2.Final, 10.0.0.Beta1
>
>
> STOMP errors do not get logged at all, for example "HQ222068: connection closed ..." on unclean connection close.
> Also, apparently due to the same root cause (or at least fixed by the same fix), for example connecting with an unsupported STOMP version just hangs instead of responding with the ERROR frame.



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


From issues at jboss.org  Wed Dec  6 11:21:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4771) The WildFly Arquillian
 ManagementClient should not assume undertow is enabled
In-Reply-To: <JIRA.12574811.1434102776000@Atlassian.JIRA>
References: <JIRA.12574811.1434102776000@Atlassian.JIRA>
	<JIRA.12574811.1434102776000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574811.1434102776000.88451.1512577273371@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4771.
----------------------------


> The WildFly Arquillian ManagementClient should not assume undertow is enabled
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-4771
>                 URL: https://issues.jboss.org/browse/WFLY-4771
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Tristan Tarrant
>            Assignee: Tristan Tarrant
>             Fix For: 10.0.0.Alpha4
>
>
> When using wildfly-arquillian with infinispan-server, the connection to the managed server breaks with the following exception:
> java.lang.RuntimeException: org.jboss.as.arquillian.container.ManagementClient$UnSuccessfulOperationException: "WFLYCTL0030: No resource definition is registered for address [(\"subsystem\" => \"undertow\")]"
> 	at org.jboss.as.arquillian.container.ManagementClient.getWebUri(ManagementClient.java:143)
> 	at org.jboss.as.arquillian.container.ManagementClient.getProtocolMetaData(ManagementClient.java:160)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:145)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> This is because the client relies on the availability of the undertow subsystem, which might not necessarily be available (as is the case with infinispan-server).



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

From issues at jboss.org  Wed Dec  6 11:21:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5151) Add support to mdb
	delivery-groups
In-Reply-To: <JIRA.12582088.1440131609000@Atlassian.JIRA>
References: <JIRA.12582088.1440131609000@Atlassian.JIRA>
	<JIRA.12582088.1440131609000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582088.1440131609000.88455.1512577273698@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5151.
----------------------------


> Add support to mdb delivery-groups
> ----------------------------------
>
>                 Key: WFLY-5151
>                 URL: https://issues.jboss.org/browse/WFLY-5151
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>            Priority: Minor
>             Fix For: 10.0.0.Beta2
>
>
> Add support to mdb delivery-groups. A delivery-group is a resource inside ejb3 subsystem. This resource can be active:
> <delivery-groups>
>     <delivery-group name="group" active="true"/>
> </delivery-groups>
> Whenever the delivery-group is active, all mdbs belonging to that group will have a delivery active state. If the delivery-group is not active, all mdbs belonging to that group will have a delivery disabled.
> The state of delivery-groups can be controlled by cli, using the commands:
> ./subsystem=ejb3/mdb-delivery-group=group:add
> ./subsystem=ejb3/mdb-delivery-group=group:remove
> ./subsystem=ejb3/mdb-delivery-group=group:write-attribute(name=active,value=true)
> An MDB can be associated with a delivery-group at jboss-ejb3.xml or with an annotation.



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

From issues at jboss.org  Wed Dec  6 11:21:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5007) After fix for WFLY-4844
 concurrency management interceptor uses incorrect access timeout
In-Reply-To: <JIRA.12579399.1437979586000@Atlassian.JIRA>
References: <JIRA.12579399.1437979586000@Atlassian.JIRA>
	<JIRA.12579399.1437979586000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579399.1437979586000.88458.1512577273962@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5007.
----------------------------


> After fix for WFLY-4844 concurrency management interceptor uses incorrect access timeout
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5007
>                 URL: https://issues.jboss.org/browse/WFLY-5007
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Beta1
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:14 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4705) Enable interface declaration
 in subsystem template
In-Reply-To: <JIRA.12573343.1432934449000@Atlassian.JIRA>
References: <JIRA.12573343.1432934449000@Atlassian.JIRA>
	<JIRA.12573343.1432934449000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573343.1432934449000.88463.1512577274248@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4705.
----------------------------


> Enable interface declaration in subsystem template
> --------------------------------------------------
>
>                 Key: WFLY-4705
>                 URL: https://issues.jboss.org/browse/WFLY-4705
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Build System, IIOP
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>            Priority: Optional
>             Fix For: 10.0.0.Alpha4
>
>
> Currently interfaces cannot be defined in subsystem templates. As a result of "unsecure" interface, which is used only by iiop subsystem, is defined in main template file and it's included in all subsystems configurations. Implement extension to feature pack plugin which enables specifying interfaces in subsystem configuration files and move "unsecure" interface configuration from main template to jacorb.



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

From issues at jboss.org  Wed Dec  6 11:21:14 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5201) Do not use newly disallowed
 characters in jgroups runtime metric attributes names
In-Reply-To: <JIRA.12582562.1440517191000@Atlassian.JIRA>
References: <JIRA.12582562.1440517191000@Atlassian.JIRA>
	<JIRA.12582562.1440517191000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582562.1440517191000.88467.1512577274479@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5201.
----------------------------


> Do not use newly disallowed characters in jgroups runtime metric attributes names
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-5201
>                 URL: https://issues.jboss.org/browse/WFLY-5201
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Domain Management
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 10.0.0.CR1
>
>
> When doing a :read-resource(include-runtime=true,recursive=true) this blows up. Debugging shows that to be because e.g. the resource  /subsystem=jgroups/channel=ee/protocol=UDP contains metrics called things like 
> {code}
>  "timer.keep_alive_time" => {
>                 "type" => LONG,
>                 "description" => "Timeout in ms to remove idle threads from the timer pool",
>                 "expressions-allowed" => false,
>                 "nillable" => false,
>                 "access-type" => "metric",
>                 "storage" => "runtime"
>             },
>             "timer.max_threads" => {
>                 "type" => INT,
>                 "description" => "Max thread pool size for the timer thread pool",
>                 "expressions-allowed" => false,
>                 "nillable" => false,
>                 "access-type" => "metric",
>                 "storage" => "runtime"
>             },
>             "timer.min_threads" => {
>                 "type" => INT,
>                 "description" => "Minimum thread pool size for the timer thread pool",
>                 "expressions-allowed" => false,
>                 "nillable" => false,
>                 "access-type" => "metric",
>                 "storage" => "runtime"
>             },
> {code}
> i.e. they have a dot in their name. So when the r-r handler wants to read the attributes it in effect tries to do the following demonstrated by CLI commands:
> {code}
> [standalone at localhost:9990 /] /subsystem=jgroups/channel=ee/protocol=UDP:read-attribute(name=timer
> timer.keep_alive_time   timer.min_threads       timer.rejection_policy  timer.wheel_size        timer_queue_size        timer_threads           
> timer.max_threads       timer.queue_max_size    timer.tick_time         timer_class             timer_tasks             timer_type              
> [standalone at localhost:9990 /] /subsystem=jgroups/channel=ee/protocol=UDP:read-attribute(name=timer.max_threads)      
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0201: Unknown attribute 'timer'",
>     "rolled-back" => true
> }
> {code}
> I see ReadResourceHandler has some stuff to extract the attribute name if 'extended syntax' is used. So we have two options:
> 1) Ban dots in metric/attribute names
> 2) Add a workaround to fall back. In other words if ReadAttributeHandler thinks extended syntax is being used, and cannot find the extracted 'timer' attribute, then try the full non-extracted name, e.g. timer.max_threads, and only then error.



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

From issues at jboss.org  Wed Dec  6 11:21:14 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5025) Suspending server has no
 effect for root context
In-Reply-To: <JIRA.12579763.1438176595000@Atlassian.JIRA>
References: <JIRA.12579763.1438176595000@Atlassian.JIRA>
	<JIRA.12579763.1438176595000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579763.1438176595000.88472.1512577274836@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5025.
----------------------------


> Suspending server has no effect for root context
> ------------------------------------------------
>
>                 Key: WFLY-5025
>                 URL: https://issues.jboss.org/browse/WFLY-5025
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Beta2
>
>
> Suspending the server works only on deployed deployments but it doesn't work for root context.
> => after executing {{:suspend}} operation, requests to deployment are rejected as expected, still requests to {{http://localhost:8080}} are permitted and processed.



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

From issues at jboss.org  Wed Dec  6 11:21:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4686) Operation
 list-delivering-messages is missing in CLI
In-Reply-To: <JIRA.12572938.1432729771000@Atlassian.JIRA>
References: <JIRA.12572938.1432729771000@Atlassian.JIRA>
	<JIRA.12572938.1432729771000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572938.1432729771000.88477.1512577275424@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4686.
----------------------------


> Operation list-delivering-messages is missing in CLI
> ----------------------------------------------------
>
>                 Key: WFLY-4686
>                 URL: https://issues.jboss.org/browse/WFLY-4686
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha4
>
>
> There is missing operation list-delivering-messages on runtime-queue:
> {code}
> [standalone at localhost:9990 /] /subsystem=messaging-activemq/server=default/runtime-queue=jms.queue.testQueue:list-
> list-add                              list-get                              list-message-counter-history-as-html  list-messages-as-json                 list-scheduled-messages-as-json       
> list-clear                            list-message-counter-as-html          list-message-counter-history-as-json  list-remove                           
> list-consumers-as-json                list-message-counter-as-json          list-messages                         list-scheduled-messages    
> {code}
> This was hit on Wildfly 9 with ActiveMQ (built from Jeff's branch)



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

From issues at jboss.org  Wed Dec  6 11:21:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5085) [Migration operation] If
 connector has set factory-class
 org.hornetq.core.remoting.impl.netty.NettyConnectorFactory then migration
 operation does not translate it to Artemis equivalent
In-Reply-To: <JIRA.12580957.1439376512000@Atlassian.JIRA>
References: <JIRA.12580957.1439376512000@Atlassian.JIRA>
	<JIRA.12580957.1439376512000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580957.1439376512000.88482.1512577275770@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5085.
----------------------------


> [Migration operation] If connector has set factory-class org.hornetq.core.remoting.impl.netty.NettyConnectorFactory then migration operation does not translate it to Artemis equivalent
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5085
>                 URL: https://issues.jboss.org/browse/WFLY-5085
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Beta2
>
>
> We should migrate configuration like:
> {code}
> <connector name="myconnector">
> ...
>                 <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class>
>             </connector>
> {code}
> to:
> {code}
>                 <connector name="myconnector" factory-class="org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector">
> ...
> {code}
> and not to:
> {code}
>                           <connector name="myconnector" factory-class="org.hornetq.core.remoting.impl.netty.NettyConnectorFactory">
> ...
> {code}
> The same holds for InVMConnector.



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

From issues at jboss.org  Wed Dec  6 11:21:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4796)
 IIOPTransactionPropagationTestCase fails with -Dnode0 property set
In-Reply-To: <JIRA.12575294.1434538866000@Atlassian.JIRA>
References: <JIRA.12575294.1434538866000@Atlassian.JIRA>
	<JIRA.12575294.1434538866000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575294.1434538866000.88487.1512577276122@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4796.
----------------------------


> IIOPTransactionPropagationTestCase fails with -Dnode0 property set
> ------------------------------------------------------------------
>
>                 Key: WFLY-4796
>                 URL: https://issues.jboss.org/browse/WFLY-4796
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Test Suite
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>             Fix For: 10.0.0.Alpha4
>
>
> org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase fails once -Dnode0 and -Dnode1 properties are used.
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 19,243.526 sec <<< FAILURE! - in org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase
> org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase  Time elapsed: 19,241.627 sec  <<< ERROR!
> javax.naming.CommunicationException: Cannot connect to ORB
> 	at sun.nio.ch.Net.connect0(Native Method)
> 	at sun.nio.ch.Net.connect(Net.java:458)
> 	at sun.nio.ch.Net.connect(Net.java:450)
> 	at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
> 	at java.nio.channels.SocketChannel.open(SocketChannel.java:189)
> 	at com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl.createSocket(DefaultSocketFactoryImpl.java:95)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:207)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:236)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:119)
> 	at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:187)
> 	at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:137)
> 	at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:229)
> 	at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:130)
> 	at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:69)
> 	at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:381)
> 	at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:247)
> 	at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:105)
> 	at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:49)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.InitialContext.<init>(InitialContext.java:216)
> 	at org.jboss.as.test.iiop.client.Util.getContext(Util.java:130)
> 	at org.jboss.as.test.iiop.client.IIOPTransactionPropagationTestCase.beforeClass(IIOPTransactionPropagationTestCase.java:102)
> {noformat}
> Fix
> {noformat}
> --- a/testsuite/integration/iiop/src/test/java/org/jboss/as/test/iiop/client/Util.java
> +++ b/testsuite/integration/iiop/src/test/java/org/jboss/as/test/iiop/client/Util.java
> @@ -56,7 +56,7 @@ import com.arjuna.orbportability.ORB;
>  import com.sun.corba.se.impl.orbutil.ORBConstants;
>  
>  public class Util {
> -    public static final String HOST = NetworkUtils.formatPossibleIpv6Address(System.getProperty("node0", "localhost"));
> +    public static final String HOST = NetworkUtils.formatPossibleIpv6Address(System.getProperty("node1", "localhost"));
>      private static ORB orb = null;
>  
>      // Recovery manager is needed till the end of orb usage
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:21:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5277) Upgrade HAL to 2.8.7
In-Reply-To: <JIRA.12583971.1441360127000@Atlassian.JIRA>
References: <JIRA.12583971.1441360127000@Atlassian.JIRA>
	<JIRA.12583971.1441360127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583971.1441360127000.88490.1512577276481@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5277.
----------------------------


> Upgrade HAL to 2.8.7
> --------------------
>
>                 Key: WFLY-5277
>                 URL: https://issues.jboss.org/browse/WFLY-5277
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5091) User supplied externalizers
 are ignored by web/ejb clustering code
In-Reply-To: <JIRA.12580997.1439388647000@Atlassian.JIRA>
References: <JIRA.12580997.1439388647000@Atlassian.JIRA>
	<JIRA.12580997.1439388647000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580997.1439388647000.88495.1512577276710@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5091.
----------------------------


> User supplied externalizers are ignored by web/ejb clustering code
> ------------------------------------------------------------------
>
>                 Key: WFLY-5091
>                 URL: https://issues.jboss.org/browse/WFLY-5091
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>
> Several users were surprised to find that their custom Infinispan externalizers are not used when marshalling of objects placed in the web session or used as fields in their SFSB.  Without this functionality, users cannot use non-serializable objects in their web session or SFSB.
> There are a few reasons why this does not currently work:
> # The cache in which user objects is placed does not scan the application classloader for externalizers.
> # In both the web and ejb case, user objects are stored within a MarshalledValue - the serialization of which is done by JBoss Marshalling directly, not via Infinispan's marshaller.
> # Neither the org.infinispan.commons (containing org.infinispan.commons.marshall.AdvancedExternalizer) nor org.jboss.marshalling (containing org.jboss.marshalling.Externalizer) modules are exported to the application classpath.
> Clearly, we need a common, public mechanism that bridges these two APIs so that users can register custom externalizers without needing to know the specific marshalling framework to which to adhere.



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

From issues at jboss.org  Wed Dec  6 11:21:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4048) Make sure predicated handlers
 (like handler-info.conf) can be used at a server level
In-Reply-To: <JIRA.12556600.1415067260000@Atlassian.JIRA>
References: <JIRA.12556600.1415067260000@Atlassian.JIRA>
	<JIRA.12556600.1415067260000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556600.1415067260000.88501.1512577277114@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4048.
----------------------------


> Make sure predicated handlers (like handler-info.conf) can be used at a server level
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-4048
>                 URL: https://issues.jboss.org/browse/WFLY-4048
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha3
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4869) Failed to start statistics
 service for datasources
In-Reply-To: <JIRA.12577099.1436176560000@Atlassian.JIRA>
References: <JIRA.12577099.1436176560000@Atlassian.JIRA>
	<JIRA.12577099.1436176560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577099.1436176560000.88507.1512577277357@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4869.
----------------------------


> Failed to start statistics service for datasources
> --------------------------------------------------
>
>                 Key: WFLY-4869
>                 URL: https://issues.jboss.org/browse/WFLY-4869
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Alpha5
>
>         Attachments: jaxws-samples-wsrm-store.war
>
>
> 11:45:40,471 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-7) WFLYJCA0001: Bound data source [java:jboss/datasources/rmclientdb]
> 11:45:40,472 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.data-source.java:jboss/datasources/rmclientdb.statistics: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/rmclientdb.statistics: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 	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.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subsystem=datasources/data-source=*/statistics=jdbc'
> 	at org.jboss.as.controller.registry.NodeSubregistry.register(NodeSubregistry.java:86)
> 	at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:176)
> 	at org.jboss.as.connector.services.datasources.statistics.DataSourceStatisticsService.start(DataSourceStatisticsService.java:83)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	... 3 more
> reproducible w/ attached deployment



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

From issues at jboss.org  Wed Dec  6 11:21:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3872) Recurring failure of
 EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn
In-Reply-To: <JIRA.12552711.1411091031000@Atlassian.JIRA>
References: <JIRA.12552711.1411091031000@Atlassian.JIRA>
	<JIRA.12552711.1411091031000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552711.1411091031000.88516.1512577277565@Atlassian.JIRA>


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

Kabir Khan closed WFLY-3872.
----------------------------


> Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3872
>                 URL: https://issues.jboss.org/browse/WFLY-3872
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Beta2
>
>
> Since https://github.com/wildfly/wildfly/pull/6660 was submitted, EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn is failing regularly. Not every time but very often.
> Alessio, you mentioned seeing some error logging from XAResourceRecoveryImpl, but that's in the logs on successful runs as well, and occurs prior to the test as well. That's a period background task from the transaction manager trying to perform recovery of some previous transaction. I don't see why it would have any impact on this test.



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

From issues at jboss.org  Wed Dec  6 11:21:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4577) Missing dependency "ibm.jdk"
 in module org.jboss.security.negotiation
In-Reply-To: <JIRA.12567904.1428491468000@Atlassian.JIRA>
References: <JIRA.12567904.1428491468000@Atlassian.JIRA>
	<JIRA.12567904.1428491468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567904.1428491468000.88521.1512577277730@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4577.
----------------------------


> Missing dependency "ibm.jdk" in module org.jboss.security.negotiation
> ---------------------------------------------------------------------
>
>                 Key: WFLY-4577
>                 URL: https://issues.jboss.org/browse/WFLY-4577
>             Project: WildFly
>          Issue Type: Enhancement
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Juraj Dur?ni
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> The module org.jboss.security.negotiation is missing "ibm.jdk" dependency. This module is needed if the JDV is running on IBM jdk - contains com.ibm.security.auth.module.Krb5LoginModule class.



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


From issues at jboss.org  Wed Dec  6 11:21:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4586) Provide JMS backward
	compatibility
In-Reply-To: <JIRA.12570690.1430816254000@Atlassian.JIRA>
References: <JIRA.12570690.1430816254000@Atlassian.JIRA>
	<JIRA.12570690.1430816254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570690.1430816254000.88526.1512577277827@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4586.
----------------------------


> Provide JMS backward compatibility
> ----------------------------------
>
>                 Key: WFLY-4586
>                 URL: https://issues.jboss.org/browse/WFLY-4586
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> New JMS clients (from WildFly 10) must be able to communicate with older WildFly 9 with HornetQ.



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

From issues at jboss.org  Wed Dec  6 11:21:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5253) [Migration operation] [Web to
 Undertow] Protocol attribute in ssl configuration of https connector is not
 properly migrated
In-Reply-To: <JIRA.12583453.1441118790000@Atlassian.JIRA>
References: <JIRA.12583453.1441118790000@Atlassian.JIRA>
	<JIRA.12583453.1441118790000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583453.1441118790000.88530.1512577277932@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5253.
----------------------------


> [Migration operation] [Web to Undertow] Protocol attribute in ssl configuration of https connector is not properly migrated
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5253
>                 URL: https://issues.jboss.org/browse/WFLY-5253
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> In Web {{protocol}} attribute of https ssl configuration is used for defining ssl protocols such as TLSv1.2. This attribute isn't properly migrated. Migrate operation defines {{enabled-protocols}} in {{https-listener}} based on Web's {{ssl-protocol}} which is incorrect as {{ssl-protocol}} in Web stands for name of custom ssl protocol provider.



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

From issues at jboss.org  Wed Dec  6 11:21:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4873) Update the servlet feature
 pack templates to use version 4.0 of the schema, 
In-Reply-To: <JIRA.12577143.1436212175000@Atlassian.JIRA>
References: <JIRA.12577143.1436212175000@Atlassian.JIRA>
	<JIRA.12577143.1436212175000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577143.1436212175000.88533.1512577277993@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4873.
----------------------------


> Update the servlet feature pack templates to use version 4.0 of the schema,
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-4873
>                 URL: https://issues.jboss.org/browse/WFLY-4873
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 10.0.0.Alpha5
>
>
> It appears many of the templates are still stuck on version 2.1



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

From issues at jboss.org  Wed Dec  6 11:21:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4638) EntityBean instances are
 leaked from pool if exception is thrown during instance activation
In-Reply-To: <JIRA.12571803.1431684300000@Atlassian.JIRA>
References: <JIRA.12571803.1431684300000@Atlassian.JIRA>
	<JIRA.12571803.1431684300000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571803.1431684300000.88536.1512577278053@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4638.
----------------------------


> EntityBean instances are leaked from pool if exception is thrown during instance activation
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4638
>                 URL: https://issues.jboss.org/browse/WFLY-4638
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.CR2, 10.0.0.Alpha1
>            Reporter: Alexey Makhmutov
>            Assignee: Alexey Makhmutov
>             Fix For: 10.0.0.Alpha2
>
>
> This is addition to WFLY-4569.
> One more case was discovered when bean is leaked from the pool after an exception is thrown in certain methods:
> * If any exception is thrown during call to instance.activate() (which includes calls to ejbActivate and ejbLoad), then cache implementations (both optimistic and pessimistic) never notifies pool that instance should be discarded.
> In addition, a little correction should be made for handling exceptions thrown from ejbCreate (handling was introduced as part of WFLY-4569) -- such instances should not be released to the pool, but discarded with pool notification in order to comply with EJB specification.



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

From issues at jboss.org  Wed Dec  6 11:21:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4452) Use
 Flag.RESTART_RESOURCE_SERVICES for child resources of cache
In-Reply-To: <JIRA.12566545.1426884197000@Atlassian.JIRA>
References: <JIRA.12566545.1426884197000@Atlassian.JIRA>
	<JIRA.12566545.1426884197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566545.1426884197000.88541.1512577278250@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4452.
----------------------------


> Use Flag.RESTART_RESOURCE_SERVICES for child resources of cache
> ---------------------------------------------------------------
>
>                 Key: WFLY-4452
>                 URL: https://issues.jboss.org/browse/WFLY-4452
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Alpha6
>
>
> Currently, the attributes for each child resource of a cache use RESTART_ALL_SERVICES, thus any change to one of these attributes requires all services to restart.  This is overkill, since only the services of the parent resource (i.e. cache) actually require restarting.
> Ideally, each child resource should create a runtime service for its corresponding sub-configuration.  e.g. the transaction resource would create a Service<TransactionConfiguration>.  Thus the cache resource's add handler becomes much less complex - and the corresponding Service<Configuration> need only depend on the sub-configuration services for each child resource.



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

From issues at jboss.org  Wed Dec  6 11:21:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4308) Proxies created via
 ContextService.createContextualProxy(...) are not Serializable
In-Reply-To: <JIRA.12562319.1422971804000@Atlassian.JIRA>
References: <JIRA.12562319.1422971804000@Atlassian.JIRA>
	<JIRA.12562319.1422971804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562319.1422971804000.88547.1512577278393@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4308.
----------------------------


> Proxies created via ContextService.createContextualProxy(...) are not Serializable
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-4308
>                 URL: https://issues.jboss.org/browse/WFLY-4308
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> Setting priority to critical since, I believe, this is a matter of compliance with the concurrency utilities specification.
> Section 3.3.4 of the specification states that:
> "All invocation handlers for the contextual proxy implementation must implement java.io.Serializable."
> While the invocation handler of the generated proxy does indeed implement Serializable, it contains a reference to org.jboss.as.server.moduleservice.ServiceModuleLoader (among others), which is not serializable, thus attempts to serialize the proxies generated via ContextService.createContextualProxy(...) via JBoss Marshalling throw a org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.server.moduleservice.ServiceModuleLoader



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

From issues at jboss.org  Wed Dec  6 11:21:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5005) jacorb migration does not
 work in standalone mode
In-Reply-To: <JIRA.12579286.1437733083000@Atlassian.JIRA>
References: <JIRA.12579286.1437733083000@Atlassian.JIRA>
	<JIRA.12579286.1437733083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579286.1437733083000.88553.1512577278516@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5005.
----------------------------


> jacorb migration does not work in standalone mode
> -------------------------------------------------
>
>                 Key: WFLY-5005
>                 URL: https://issues.jboss.org/browse/WFLY-5005
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Jeff Mesnil
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.Beta2
>
>
> I was checking the messaging migration (for WFLY-5004) and I was wondering whether the jacorb migration was also working in domain mode.
> It fails with an error but it also happens in standalone mode.
> Steps to reproduce:
> 1. edit the wildfly standalone-full.xml and replace the iiop-openjdk configuration from the template in legacy/jacorb resources (with the socket-bindings too):
> {noformat}
>    <subsystem xmlns="urn:jboss:domain:jacorb:2.0">
>        <orb persistent-server-id="1" socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
>            <initializers transactions="spec" security="identity"/>
>        </orb>
>        <naming root-context="JBoss/Naming/root" export-corbaloc="on"/>
>    </subsystem>
> {noformat}
> 2. start the server in admin-only
> 3.  perform the migration 
> {noformat}
> /subsystem=jacorb:migrate
> {
>     "outcome" => "success",
>     "result" => [("iiop-openjdk" => "1.0.0")]
> }
> {noformat}
> 4. reload the server in normal mode. 
> => it fails with the error:
> {noformat}
> 12:09:24,138 INFO  [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 63) WFLYIIOP0001: Activating IIOP Subsystem
> 12:09:24,138 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0003: Undertow 1.3.0.Beta4 starting
> 12:09:24,144 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.NumberFormatException: For input string: "undefined"
>         at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:142)
>         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.lang.NumberFormatException: For input string: "undefined"
>         at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>         at java.lang.Integer.parseInt(Integer.java:580)
>         at java.lang.Integer.<init>(Integer.java:867)
>         at com.sun.corba.se.spi.orb.OperationFactory$IntegerAction.operate(OperationFactory.java:224)
>         at com.sun.corba.se.spi.orb.OperationFactory$ListAction.operate(OperationFactory.java:397)
>         at com.sun.corba.se.spi.orb.OperationFactory$ComposeAction.operate(OperationFactory.java:475)
>         at com.sun.corba.se.impl.orb.NormalParserAction.apply(NormalParserAction.java:47)
>         at com.sun.corba.se.spi.orb.PropertyParser.parse(PropertyParser.java:70)
>         at com.sun.corba.se.spi.orb.ParserImplBase.init(ParserImplBase.java:74)
>         at com.sun.corba.se.impl.orb.ORBDataParserImpl.<init>(ORBDataParserImpl.java:408)
>         at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:456)
>         at com.sun.corba.se.impl.orb.ORBImpl.set_parameters(ORBImpl.java:543)
>         at org.omg.CORBA.ORB.init(ORB.java:353)
>         at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:126)
>         ... 5 more
> {noformat}
> The giop-version in  XML configuration after migration looks indeed wrong:
> {noformat}
>         <subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
>             <orb ssl-socket-binding="jacorb-ssl" socket-binding="jacorb" giop-version="1.undefined"/>
>             <initializers transactions="spec" security="identity"/>
>             <security add-component-via-interceptor="false"/>
>         </subsystem>
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:21:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5172) Drop RSVP from default
	protocol stacks
In-Reply-To: <JIRA.12582219.1440175524000@Atlassian.JIRA>
References: <JIRA.12582219.1440175524000@Atlassian.JIRA>
	<JIRA.12582219.1440175524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582219.1440175524000.88558.1512577278644@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5172.
----------------------------


> Drop RSVP from default protocol stacks
> --------------------------------------
>
>                 Key: WFLY-5172
>                 URL: https://issues.jboss.org/browse/WFLY-5172
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta2
>
>
> Infinispan no longer flags any messages using Flag.RSVP, and therefore no longer requires RSVP in its protocol stack.



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

From issues at jboss.org  Wed Dec  6 11:21:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4838) Add smoke test for cloning
	profiles in CLI
In-Reply-To: <JIRA.12576448.1435568048000@Atlassian.JIRA>
References: <JIRA.12576448.1435568048000@Atlassian.JIRA>
	<JIRA.12576448.1435568048000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576448.1435568048000.88561.1512577278736@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4838.
----------------------------


> Add smoke test for cloning profiles in CLI
> ------------------------------------------
>
>                 Key: WFLY-4838
>                 URL: https://issues.jboss.org/browse/WFLY-4838
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>             Fix For: 10.0.0.Alpha5
>
>
> https://issues.jboss.org/browse/EAP7-35 provides profile cloning ability (runtime (CLI)) to create new profiles based on existing JBoss profiles (web, full, web-ha, full-ha).
> This test serves as basic smoke tests to be run within the testsuite.
> This test should be in WildFly TS (not WildFly Core TS), because WildFly has more complex default profile in domain part of TS than WildFly Core.
> CloneProfileTestCase:
> * clone default profile via CLI
> * check results



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


From issues at jboss.org  Wed Dec  6 11:21:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4530) Port jboss-as-ejb3_1_5.xsd to
	WildFly
In-Reply-To: <JIRA.12568733.1429286493000@Atlassian.JIRA>
References: <JIRA.12568733.1429286493000@Atlassian.JIRA>
	<JIRA.12568733.1429286493000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568733.1429286493000.88565.1512577278851@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4530.
----------------------------


> Port jboss-as-ejb3_1_5.xsd to WildFly
> -------------------------------------
>
>                 Key: WFLY-4530
>                 URL: https://issues.jboss.org/browse/WFLY-4530
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: EJB
>            Reporter: Darran Lofthouse
>            Assignee: Richard Opalka
>             Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4340) use-try-lock exposed for
 <connection-definition>
In-Reply-To: <JIRA.12562964.1423677548000@Atlassian.JIRA>
References: <JIRA.12562964.1423677548000@Atlassian.JIRA>
	<JIRA.12562964.1423677548000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562964.1423677548000.88568.1512577278920@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4340.
----------------------------


> use-try-lock exposed for <connection-definition>
> ------------------------------------------------
>
>                 Key: WFLY-4340
>                 URL: https://issues.jboss.org/browse/WFLY-4340
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.2.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 10.0.0.Beta1
>
>
> <connection-definition> DMR:
> {noformat}
> use-try-lock                    undefined                                               LONG
> {noformat}
> which should be removed



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

From issues at jboss.org  Wed Dec  6 11:21:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6
 addresses in server log
In-Reply-To: <JIRA.12583358.1441077545000@Atlassian.JIRA>
References: <JIRA.12583358.1441077545000@Atlassian.JIRA>
	<JIRA.12583358.1441077545000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583358.1441077545000.88574.1512577279109@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5242.
----------------------------


> Inconsistent format for IPv6 addresses in server log
> ----------------------------------------------------
>
>                 Key: WFLY-5242
>                 URL: https://issues.jboss.org/browse/WFLY-5242
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Lyle Wang
>            Assignee: Chao Wang
>            Priority: Minor
>             Fix For: 10.0.0.CR1
>
>
> Description of problem:
> When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs.
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports)
> 2. Start WildFly and check the log
> Actual results:
> ----------------------------------------
> 2015-08-31 12:51:47,812 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080
> ......
> 2015-08-31 12:51:48,431 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management
> 2015-08-31 12:51:48,432 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993
> ----------------------------------------
> In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management"
> Expected results:
> Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ].



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

From issues at jboss.org  Wed Dec  6 11:21:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4824) Build fails downloading
 licenses due to insufficient heap space
In-Reply-To: <JIRA.12576055.1435073461000@Atlassian.JIRA>
References: <JIRA.12576055.1435073461000@Atlassian.JIRA>
	<JIRA.12576055.1435073461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576055.1435073461000.88578.1512577279201@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4824.
----------------------------


> Build fails downloading licenses due to insufficient heap space
> ---------------------------------------------------------------
>
>                 Key: WFLY-4824
>                 URL: https://issues.jboss.org/browse/WFLY-4824
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 10.0.0.Alpha3
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Optional
>             Fix For: 10.0.0.Alpha4
>
>
> In our CI cluster we regularly see failures building the feature-pack module due to lack of heap space. Increasing it to 1024 seems to be enough to avoid these intermittent failures. Example output:
> {code}
> [INFO] --- maven-assembly-plugin:2.5.3:single (assemble) @ wildfly-feature-pack ---
> [INFO] Reading assembly descriptor: assembly.xml
> [INFO] Building zip: /home/mmusgrov/source/forks/narayana/jboss-as/feature-pack/target/wildfly-10.0.0.Alpha3-SNAPSHOT.zip
> [INFO] 
> [INFO] --- license-maven-plugin:1.8:download-licenses (default) @ wildfly-feature-pack ---
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 07:09 min
> [INFO] Finished at: 2015-06-23T16:21:09+01:00
> [INFO] Final Memory: 60M/399M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Java heap space -> [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/OutOfMemoryError
> {code}



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

From issues at jboss.org  Wed Dec  6 11:21:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4816) Add new ContextService needs
	reload
In-Reply-To: <JIRA.12575855.1434974618000@Atlassian.JIRA>
References: <JIRA.12575855.1434974618000@Atlassian.JIRA>
	<JIRA.12575855.1434974618000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575855.1434974618000.88582.1512577279314@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4816.
----------------------------


> Add new ContextService needs reload
> -----------------------------------
>
>                 Key: WFLY-4816
>                 URL: https://issues.jboss.org/browse/WFLY-4816
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>            Reporter: Hynek ?v?bek
>            Assignee: Eduardo Martins
>             Fix For: 9.0.1.Final, 10.0.0.Alpha6
>
>
> Add new ContextService needs reload. Other Concurrency Utils don't need reload....
> Example is here:
> https://github.com/hsvabek/wildfly/tree/test_context_service
> EEConcurrentManagementTestCase.testContextServiceManagement()



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


From issues at jboss.org  Wed Dec  6 11:21:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4559) Add support for development
 mode to Weld's management model
In-Reply-To: <JIRA.12569822.1430134118000@Atlassian.JIRA>
References: <JIRA.12569822.1430134118000@Atlassian.JIRA>
	<JIRA.12569822.1430134118000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569822.1430134118000.88585.1512577279374@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4559.
----------------------------


> Add support for development mode to Weld's management model
> -----------------------------------------------------------
>
>                 Key: WFLY-4559
>                 URL: https://issues.jboss.org/browse/WFLY-4559
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             Fix For: 10.0.0.Alpha3
>
>
> http://docs.jboss.org/weld/reference/3.0.0.Alpha9/en-US/html/devmode.html
> http://weld.cdi-spec.org/news/2015/02/05/weld-300Alpha4/



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

From issues at jboss.org  Wed Dec  6 11:21:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4906) Serialization failure for
 maps with null values
In-Reply-To: <JIRA.12577761.1436706282000@Atlassian.JIRA>
References: <JIRA.12577761.1436706282000@Atlassian.JIRA>
	<JIRA.12577761.1436706282000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577761.1436706282000.88591.1512577279579@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4906.
----------------------------


> Serialization failure for maps with null values
> -----------------------------------------------
>
>                 Key: WFLY-4906
>                 URL: https://issues.jboss.org/browse/WFLY-4906
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 9.0.0.Final
>            Reporter: Aparna Chaudhary
>            Assignee: Stuart Douglas
>              Labels: jackson
>             Fix For: 10.0.0.Alpha6
>
>
> Serialization of generic map with null values results in _java.lang.UnsupportedOperationException: Type id handling not implemented for type java.lang.Object_.
> The issue is fixed in jackson-databind 2.5.2 https://github.com/FasterXML/jackson-databind/issues/691



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

From issues at jboss.org  Wed Dec  6 11:21:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.88598.1512577279858@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5213.
----------------------------


> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



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


From issues at jboss.org  Wed Dec  6 11:21:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5197) Intermittent
 javax.ejb.EJBException: Do not call non-public methods on EJB's
In-Reply-To: <JIRA.12582429.1440496965000@Atlassian.JIRA>
References: <JIRA.12582429.1440496965000@Atlassian.JIRA>
	<JIRA.12582429.1440496965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582429.1440496965000.88606.1512577280050@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5197.
----------------------------


> Intermittent javax.ejb.EJBException: Do not call non-public methods on EJB's
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5197
>                 URL: https://issues.jboss.org/browse/WFLY-5197
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Tomas Remes
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>
> It's intermittently failing in CDI TCK in org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest. There is:
> {code}
> @Stateful
> @Interceptors(CatInterceptor.class)
> public class Cat extends Animal {
>  ...
>     @Override
>     public void foo() {
>     }
>  ...
> }
> {code} 
> and:
> {code}
> public abstract class Animal {
>  
>  ...
>     void foo() {
>     }
>  ....
> }
> {code}
> There is check in {{org.jboss.as.ejb3.component.session.SessionBeanComponentDescription#addNoInterfaceView}} whether method is public. This check is sometimes called for {{Animal.foo()}} and sometimes for {{Cat.foo()}}. I think only {{Cat.foo()}} should be checked. 
> Stacktrace is:
> {noformat}
> javax.ejb.EJBException: WFLYEJB0224: Not a business method void org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.Animal.foo(). Do not call non-public methods on EJB's
> 	at org.jboss.as.ejb3.component.session.NotBusinessMethodInterceptor.processInvocation(NotBusinessMethodInterceptor.java:43)
> 	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.cdi.tck.interceptors.tests.contract.lifecycleCallback.Cat$$$view2.foo(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:483)
> 	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.cdi.tck.interceptors.tests.contract.lifecycleCallback.Cat$Proxy$_$$_Weld$EnterpriseProxy$.foo(Unknown Source)
> 	at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest.createAndDestroyInstance(LifecycleCallbackInterceptorTest.java:87)
> 	at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest.testLifecycleCallbackInterceptorTransactionContext(LifecycleCallbackInterceptorTest.java:137)
> {noformat}



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

From issues at jboss.org  Wed Dec  6 11:21:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4229) Make http status return while
 deploying configurable
In-Reply-To: <JIRA.12560453.1420649506000@Atlassian.JIRA>
References: <JIRA.12560453.1420649506000@Atlassian.JIRA>
	<JIRA.12560453.1420649506000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560453.1420649506000.88611.1512577280181@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4229.
----------------------------


> Make http status return while deploying configurable
> ----------------------------------------------------
>
>                 Key: WFLY-4229
>                 URL: https://issues.jboss.org/browse/WFLY-4229
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Alpha4
>
>
> For deployment behind proxies it would be more than welcome to have server return 503 instead of 404 while application is deploying.



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

From issues at jboss.org  Wed Dec  6 11:21:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4770) Upgrade HAL to 2.8.0.Alpha0
In-Reply-To: <JIRA.12574762.1434047852000@Atlassian.JIRA>
References: <JIRA.12574762.1434047852000@Atlassian.JIRA>
	<JIRA.12574762.1434047852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574762.1434047852000.88614.1512577280244@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4770.
----------------------------


> Upgrade HAL to 2.8.0.Alpha0
> ---------------------------
>
>                 Key: WFLY-4770
>                 URL: https://issues.jboss.org/browse/WFLY-4770
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.Alpha3
>
>
> HAL 2.7.1 contains a critical bugfix for HAL-617.



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

From issues at jboss.org  Wed Dec  6 11:21:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4812) Upgrade Infinispan to
	7.2.3.Final
In-Reply-To: <JIRA.12575753.1434740796000@Atlassian.JIRA>
References: <JIRA.12575753.1434740796000@Atlassian.JIRA>
	<JIRA.12575753.1434740796000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575753.1434740796000.88619.1512577280333@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4812.
----------------------------


> Upgrade Infinispan to 7.2.3.Final
> ---------------------------------
>
>                 Key: WFLY-4812
>                 URL: https://issues.jboss.org/browse/WFLY-4812
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 9.0.0.CR2, 10.0.0.Alpha3
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4746) SSO cookie-name attribute is
	ignored
In-Reply-To: <JIRA.12573892.1433423155000@Atlassian.JIRA>
References: <JIRA.12573892.1433423155000@Atlassian.JIRA>
	<JIRA.12573892.1433423155000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573892.1433423155000.88623.1512577280404@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4746.
----------------------------


> SSO cookie-name attribute is ignored
> ------------------------------------
>
>                 Key: WFLY-4746
>                 URL: https://issues.jboss.org/browse/WFLY-4746
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5032) Authentication token in
 session triggers replication of session each request
In-Reply-To: <JIRA.12579812.1438193895000@Atlassian.JIRA>
References: <JIRA.12579812.1438193895000@Atlassian.JIRA>
	<JIRA.12579812.1438193895000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579812.1438193895000.88628.1512577280570@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5032.
----------------------------


> Authentication token in session triggers replication of session each request
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5032
>                 URL: https://issues.jboss.org/browse/WFLY-5032
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta1
>
>
> If an authentication token exists in the web session, and the user is using FORM or a custom authentication mechanism, then that token is read from the session each request.  The token is treated as a mutable object by the clustering code and triggers replication of the session on each request.
> Annotating this with @Immutable will fix the problem.



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

From issues at jboss.org  Wed Dec  6 11:21:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4800) No reload required when add
 mime-mapping to servlet-container
In-Reply-To: <JIRA.12575366.1434554764000@Atlassian.JIRA>
References: <JIRA.12575366.1434554764000@Atlassian.JIRA>
	<JIRA.12575366.1434554764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575366.1434554764000.88633.1512577280658@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4800.
----------------------------


> No reload required when add mime-mapping to servlet-container
> -------------------------------------------------------------
>
>                 Key: WFLY-4800
>                 URL: https://issues.jboss.org/browse/WFLY-4800
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Alpha3
>            Reporter: Jan Stourac
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha4
>
>         Attachments: simple-web.war
>
>
> When mime-mapping is added to servlet container then no reload of server is required, although change takes effect after server restart is performed.
> Expected behaivour is either that change takes effect immediatelly after configuration is changed or that server reload is required in response message and result of the operation.



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

From issues at jboss.org  Wed Dec  6 11:21:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2885) HttpListenerService start
 doesn't clean up if start fails
In-Reply-To: <JIRA.12531552.1391963640000@Atlassian.JIRA>
References: <JIRA.12531552.1391963640000@Atlassian.JIRA>
	<JIRA.12531552.1391963640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531552.1391963640000.88638.1512577280742@Atlassian.JIRA>


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

Kabir Khan closed WFLY-2885.
----------------------------


> HttpListenerService start doesn't clean up if start fails
> ---------------------------------------------------------
>
>                 Key: WFLY-2885
>                 URL: https://issues.jboss.org/browse/WFLY-2885
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Alpha5
>
>
> HttpListenerService.prestart() does some registration stuff that doesn't get cleaned up if start() fails later on.
> I noticed this in the logs while debugging RolloutPlanTestCase failures on JDK8. Probably unrelated to those failures; just an FYI to give context.
> What happens in the test is it does an http-listener=xxx:add that is deliberately meant to fail in Stage.RUNTIME (due to a port conflict.) Later on the test does the same thing again. It's meant to fail there too, but I noticed in the logs that it failed for the *wrong reason*, before the port conflict:
> {code}
> [Server:main-one] 10:13:44,128 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.undertow.listener.maxFailOnePlan: org.jboss.msc.service.StartException in service jboss.undertow.listener.maxFailOnePlan: Failed to start service
> [Server:main-one]       at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:main-one]       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> [Server:main-one]       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> [Server:main-one]       at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> [Server:main-one] Caused by: java.lang.IllegalArgumentException: UT000053: Listener maxFailOnePlan already registered
> [Server:main-one]       at io.undertow.server.ListenerRegistry.addListener(ListenerRegistry.java:32) [undertow-core-1.0.0.CR5.jar:1.0.0.CR5]
> [Server:main-one]       at org.wildfly.extension.undertow.HttpListenerService.preStart(HttpListenerService.java:107)
> [Server:main-one]       at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:121)
> [Server:main-one]       at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:main-one]       at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:main-one]       ... 3 more
> {code}
> The error ^^^ will continue to happen until the server is restarted, even if the port conflict situation was fixed. It's because the ListenerRegistry.addListener call from the first attempt was never cleaned up.
> Cleaning up would have to be done in a catch block in ListenerService.start(). The code in stop() that normally does the cleanup does not get called if service start has failed.
> I expect we have this kind of problem in many places in the WF code.



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

From issues at jboss.org  Wed Dec  6 11:21:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5001) Undertow mod_cluster CLI:
 Control LBGroup: Enable Nodes, Disable Nodes, Stop Nodes
In-Reply-To: <JIRA.12578745.1437479976000@Atlassian.JIRA>
References: <JIRA.12578745.1437479976000@Atlassian.JIRA>
	<JIRA.12578745.1437479976000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578745.1437479976000.88643.1512577280825@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5001.
----------------------------


> Undertow mod_cluster CLI: Control LBGroup: Enable Nodes, Disable Nodes, Stop Nodes
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5001
>                 URL: https://issues.jboss.org/browse/WFLY-5001
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Michal Karm Babacek
>            Assignee: Stuart Douglas
>            Priority: Critical
>              Labels: mod_cluster
>             Fix For: 10.0.0.Beta1
>
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Control Load Balancing Groups
> For any Load Balancing Group enabled environment, it is essential to be able to Enable Nodes, Disable Nodes and Stop Nodes. These actions will enable, disable and stop all contexts with all nodes present in a particular Load Balancing Group.
> It is an equivalent of sending this MCMP message attributes ({{LB-GROUP-1}} is an arbitrary example Load Balancing Group name): 
> * Enable Nodes {{Cmd=ENABLE-APP&Range=DOMAIN&Domain=LB-GROUP-1}}
> * Disable Nodes {{Cmd=DISABLE-APP&Range=DOMAIN&Domain=LB-GROUP-1}}
> * Stop Nodes {{Cmd=STOP-APP&Range=DOMAIN&Domain=LB-GROUP-1}}
> h3. Call to action
> Enable user to carry out these actions via WildFly CLI.



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

From issues at jboss.org  Wed Dec  6 11:21:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4974) XAResource of ActiveMQ does
 not implements org.jboss.tm.XAResourceWrapper
In-Reply-To: <JIRA.12578703.1437471126000@Atlassian.JIRA>
References: <JIRA.12578703.1437471126000@Atlassian.JIRA>
	<JIRA.12578703.1437471126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578703.1437471126000.88648.1512577280969@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4974.
----------------------------


> XAResource of ActiveMQ does not implements org.jboss.tm.XAResourceWrapper
> -------------------------------------------------------------------------
>
>                 Key: WFLY-4974
>                 URL: https://issues.jboss.org/browse/WFLY-4974
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha6
>
>
> messaging-activemq subsystem does not load properly the service for ActiveMQXAResourceWrapperFactory.
> The service file contains a typo: it is org.apache.activemq.service.extensions.xa.ActiveMQXAResourceWrapperFactory while it must be org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperFactory



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

From issues at jboss.org  Wed Dec  6 11:21:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5140) NoClassDefFoundError in ha
	configuration
In-Reply-To: <JIRA.12581942.1440057381000@Atlassian.JIRA>
References: <JIRA.12581942.1440057381000@Atlassian.JIRA>
	<JIRA.12581942.1440057381000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581942.1440057381000.88657.1512577281295@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5140.
----------------------------


> NoClassDefFoundError in ha configuration
> ----------------------------------------
>
>                 Key: WFLY-5140
>                 URL: https://issues.jboss.org/browse/WFLY-5140
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.1.Final, 10.0.0.Beta2
>         Environment: Linux CentOS 7.0, jdk-8u60-linux-x64
>            Reporter: Pawe? Walczak
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>
> When testing our app with JMeter (5 concurrent users) plenty (hundreds in single request, no kidding) NoClassDefFoundErrors occur. From the client side they are visible as 500 - internal server errors. Unfortunately those errors are not easily reproducible. Not every test run is affected. Actually, I was not able to reproduce them in manual tests, just in JMeter. 
> The cluster consists of three servers in HA profile.
> Stacktrace example:
> 2015-08-20 09:42:17,966 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-236) ISPN000136: Execution error: java.lang.NoClassDefFoundError: Could not initialize class org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand
> 	at org.infinispan.commands.CommandsFactoryImpl.buildTxCompletionNotificationCommand(CommandsFactoryImpl.java:542)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.releaseLocksOnFailureBeforePrepare(PessimisticLockingInterceptor.java:252)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:138)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 2015-08-20 09:42:18,011 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-236) ISPN000136: Execution error: java.lang.NoClassDefFoundError: Could not initialize class org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand
> 	at org.infinispan.commands.CommandsFactoryImpl.buildTxCompletionNotificationCommand(CommandsFactoryImpl.java:542)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.releaseLocksOnFailureBeforePrepare(PessimisticLockingInterceptor.java:252)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:138)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:265)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:247)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> 	at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> 	at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> 	at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> 	at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:140)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:133)
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:317)
> 	at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) [:1.8.0_60]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> 	at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1212)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1207)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1184)
> 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:356)
> 	at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:97)
> 	at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:208)
> 	at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:93)
> 	at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:124)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:306)
> 	at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:86)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:150)
> 	at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:135)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:388)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:453)
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:252)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:133)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:65)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:367)
> 	at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:273)
> 	at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> 	at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)



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


From issues at jboss.org  Wed Dec  6 11:21:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5300) Expose
 org.apache.jasper.compiler.Parser.OPTIMIZE_SCRIPTLETS in the subsystem
 config
In-Reply-To: <JIRA.12584327.1441771262000@Atlassian.JIRA>
References: <JIRA.12584327.1441771262000@Atlassian.JIRA>
	<JIRA.12584327.1441771262000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584327.1441771262000.88661.1512577281463@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5300.
----------------------------


> Expose org.apache.jasper.compiler.Parser.OPTIMIZE_SCRIPTLETS in the subsystem config
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-5300
>                 URL: https://issues.jboss.org/browse/WFLY-5300
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4867) Improve Artemis interceptor
	support
In-Reply-To: <JIRA.12576998.1435913231000@Atlassian.JIRA>
References: <JIRA.12576998.1435913231000@Atlassian.JIRA>
	<JIRA.12576998.1435913231000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576998.1435913231000.88666.1512577281599@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4867.
----------------------------


> Improve Artemis interceptor support
> -----------------------------------
>
>                 Key: WFLY-4867
>                 URL: https://issues.jboss.org/browse/WFLY-4867
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> Artemis interceptors requires to tweak the org.apache.activemq.artemis module's module.xml to add a dependency to a JBoss module containing the interceptor class.
> Instead, the messaging-activemq subsystem should have a "module" attribute to load the remoting-interceptors without requiring any changes to hornetq or messaging subsystem modules.
> This will require to transform the remoting-interceptors attribute (which is a list of class names) to a complex attribute with a name and module attributes.



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

From issues at jboss.org  Wed Dec  6 11:21:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4982) Upgrade Apache DS from
 2.0.0-M15 to 2.0.0-M20 (test dependency only)
In-Reply-To: <JIRA.12578806.1437495698000@Atlassian.JIRA>
References: <JIRA.12578806.1437495698000@Atlassian.JIRA>
	<JIRA.12578806.1437495698000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578806.1437495698000.88669.1512577281699@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4982.
----------------------------


> Upgrade Apache DS from 2.0.0-M15 to 2.0.0-M20 (test dependency only)
> --------------------------------------------------------------------
>
>                 Key: WFLY-4982
>                 URL: https://issues.jboss.org/browse/WFLY-4982
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Test Suite
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Alpha6
>
>
> Upgrade the test dependency to Apache DS from 2.0.0-M15 to latest available milestone (2.0.0-M20).
> This also upgrades the transitive ehcache dependency to a more recent version (M15 pulls a *really* old version, 2.4.4), which is relevant for being able to upgrade to Apache CXF 3.1.x series without having to split the WFLY testsuite.



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

From issues at jboss.org  Wed Dec  6 11:21:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4907) Updates for Jandex 2.0 APIs
In-Reply-To: <JIRA.12577765.1436751293000@Atlassian.JIRA>
References: <JIRA.12577765.1436751293000@Atlassian.JIRA>
	<JIRA.12577765.1436751293000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577765.1436751293000.88672.1512577281751@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4907.
----------------------------


> Updates for Jandex 2.0 APIs
> ---------------------------
>
>                 Key: WFLY-4907
>                 URL: https://issues.jboss.org/browse/WFLY-4907
>             Project: WildFly
>          Issue Type: Task
>            Reporter: Jason Greene
>            Assignee: Jason Greene
>             Fix For: 10.0.0.Alpha5
>
>




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

From issues at jboss.org  Wed Dec  6 11:21:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-334) HA Singleton deployer for
	applications
In-Reply-To: <JIRA.12467417.1337972417000@Atlassian.JIRA>
References: <JIRA.12467417.1337972417000@Atlassian.JIRA>
	<JIRA.12467417.1337972417000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467417.1337972417000.88697.1512577282396@Atlassian.JIRA>


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

Kabir Khan closed WFLY-334.
---------------------------


> HA Singleton deployer for applications
> --------------------------------------
>
>                 Key: WFLY-334
>                 URL: https://issues.jboss.org/browse/WFLY-334
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Domain Management
>            Reporter: Wolf-Dieter Fink
>            Assignee: Paul Ferraro
>              Labels: deployers, hasingleton
>             Fix For: 10.0.0.Beta1
>
>
> HASingleton deployer should be provided in standalone and domain mode.
> To be able to migrate such singleton applications from former AS versions.



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

From issues at jboss.org  Wed Dec  6 11:21:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4657) EJB timer blocked after
 trigger+suspend+activate operations and JDBC storage
In-Reply-To: <JIRA.12572404.1432218865000@Atlassian.JIRA>
References: <JIRA.12572404.1432218865000@Atlassian.JIRA>
	<JIRA.12572404.1432218865000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572404.1432218865000.88701.1512577282479@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4657.
----------------------------


> EJB timer blocked after trigger+suspend+activate operations and JDBC storage
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-4657
>                 URL: https://issues.jboss.org/browse/WFLY-4657
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Jan Martiska
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha2
>
>
> Scenario:
> - The AS is configured to use a JDBC storage for EJB timers (using the H2 ExampleDS is sufficient for reproduction)
> - There is a persistent calendar timer going off every few seconds
> - The 'trigger' management operation is called on that timer
> - The timer goes off one time extra, as expected
> - The 'suspend' management operation is called on that timer
> - After a few seconds, the 'activate' operation is called on that timer
> - The timer will never go off again (not even by invoking 'trigger' operation)
> The cause:
> - Each time the timer goes off, a new java.util.TimerTask is scheduled to handle the next alarm
> - When the 'trigger' operation is invoked, the TimerServiceImpl computes the timestamp of the next alarm and schedules a new TimerTask
> - The problem is that this new TimerTask overwrites the one currently registered in the TimerServiceImpl, because the TimerServiceImpl assigns TimerTasks to Timers using a map: https://github.com/wildfly/wildfly/blob/10.0.0.Alpha1/ejb3/src/main/java/org/jboss/as/ejb3/timerservice/TimerServiceImpl.java#L905 - the TimerServiceImpl loses the reference to the previously registered TimerTask and doesn't cancel it
> - From now on, each new alarm registers the next TimerTask, but makes TimerServiceImpl forget the previous one
> - After some time, when the 'suspend' operation is called, the TimerServiceImpl cancels its stored TimerTask. However, it doesn't know that there is another scheduled elsewhere
> - The TimerTask goes off during the time when the timer is suspended. 
> - DatabaseTimerPersistence checks whether the TimerTask can run and sets the Timer's state to IN_TIMEOUT if yes (https://github.com/wildfly/wildfly/blob/10.0.0.Alpha1/ejb3/src/main/java/org/jboss/as/ejb3/timerservice/persistence/database/DatabaseTimerPersistence.java#L395). However, this is done BEFORE checking whether the timer is suspended. DatabaseTimerPersistence commits this change. Then comes the mentioned check (https://github.com/wildfly/wildfly/blob/10.0.0.Alpha1/ejb3/src/main/java/org/jboss/as/ejb3/timerservice/task/TimerTask.java#L141) and it fails, so the Timer will not go off, but the Timer state remains IN_TIMEOUT forever!
> - With every next invocation, as the timer's state remains IN_TIMEOUT, all invocations are skipped.



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

From issues at jboss.org  Wed Dec  6 11:21:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4596) Upgrade mod_cluster to
	1.3.1.Final
In-Reply-To: <JIRA.12570889.1430918355000@Atlassian.JIRA>
References: <JIRA.12570889.1430918355000@Atlassian.JIRA>
	<JIRA.12570889.1430918355000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570889.1430918355000.88705.1512577282564@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4596.
----------------------------


> Upgrade mod_cluster to 1.3.1.Final
> ----------------------------------
>
>                 Key: WFLY-4596
>                 URL: https://issues.jboss.org/browse/WFLY-4596
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> -Need to finalize and release.-
> Released now.



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

From issues at jboss.org  Wed Dec  6 11:21:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5078) Transaction subsystem
 attribute 'hornetq-store-enable-async-io' should be renamed for journal
In-Reply-To: <JIRA.12580932.1439367861000@Atlassian.JIRA>
References: <JIRA.12580932.1439367861000@Atlassian.JIRA>
	<JIRA.12580932.1439367861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580932.1439367861000.88711.1512577282698@Atlassian.JIRA>


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

Kabir Khan closed WFLY-5078.
----------------------------


> Transaction subsystem attribute 'hornetq-store-enable-async-io' should be renamed for journal
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5078
>                 URL: https://issues.jboss.org/browse/WFLY-5078
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Ondra Chaloupka
>            Assignee: Amos Feng
>             Fix For: 10.0.0.CR1
>
>
> If hornetq/artemismq journal should be used for saving txn log then transaction subsystem defines if async io libraries (if available) should be used. By default the native libraries are not used and user needs to switch for it by setting it in xml or via cli.
> {code}
> /subsystem=transactions:write-attribute(name=hornetq-store-enable-async-io, value=true)
> {code}
> For EAP7 the hornetq is going to be replaced with ActiveMQ Artemis and so artemis object store will be used instead. The attribute name should be renamed appropriately.



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

From issues at jboss.org  Wed Dec  6 11:21:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4645) access log rotates even when
 rotation is disabled by "rotate" attribute
In-Reply-To: <JIRA.12572201.1432117975000@Atlassian.JIRA>
References: <JIRA.12572201.1432117975000@Atlassian.JIRA>
	<JIRA.12572201.1432117975000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572201.1432117975000.88716.1512577282833@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4645.
----------------------------


> access log rotates even when rotation is disabled by "rotate" attribute
> -----------------------------------------------------------------------
>
>                 Key: WFLY-4645
>                 URL: https://issues.jboss.org/browse/WFLY-4645
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Alpha5
>
>
> When I disable access log rotation by setting "rotate" attribute to false:
> {code}
> /subsystem=undertow/server=default-server/host=default-host/setting=access-log/:write-attribute(name=rotate,value=false)
> {code}
> The logfile keeps rotating - how tested in "Steps to Reproduce" section.



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

From issues at jboss.org  Wed Dec  6 11:21:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-462) Eliminate the threads subsystem
In-Reply-To: <JIRA.12433050.1300303945000@Atlassian.JIRA>
References: <JIRA.12433050.1300303945000@Atlassian.JIRA>
	<JIRA.12433050.1300303945000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12433050.1300303945000.88727.1512577283069@Atlassian.JIRA>


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

Kabir Khan closed WFLY-462.
---------------------------


> Eliminate the threads subsystem
> -------------------------------
>
>                 Key: WFLY-462
>                 URL: https://issues.jboss.org/browse/WFLY-462
>             Project: WildFly
>          Issue Type: Task
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha4
>
>
> The threads subsystem should be eliminated, and instead the individual consuming subsystems should utilize common code from the jboss-as-threads module to define and manage thread pools within their own configuration models.
> Subtasks for affected subsystems.



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

From issues at jboss.org  Wed Dec  6 11:21:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4595) JSP source code leak when a
 slash added at the end of the URL
In-Reply-To: <JIRA.12570831.1430905115000@Atlassian.JIRA>
References: <JIRA.12570831.1430905115000@Atlassian.JIRA>
	<JIRA.12570831.1430905115000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570831.1430905115000.88732.1512577283216@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4595.
----------------------------


> JSP source code leak when a slash added at the end of the URL
> -------------------------------------------------------------
>
>                 Key: WFLY-4595
>                 URL: https://issues.jboss.org/browse/WFLY-4595
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.CR1
>            Reporter: Josef Cacek
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>         Attachments: jsp-source.war
>
>
> When a trailing slash is added to a JSP URL (e.g. {{localhost:8080/my-app/index.jsp/}}) the source code of the JSP is downloaded/displayed.
> This is a security issue, because users can have passwords to external systems directly stored in JSP source code.
> This was originally reported by Abhinav Gupta on [stackoverflow|http://stackoverflow.com/questions/30028346/with-trailing-slash-in-url-jsp-show-source-code]



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

From issues at jboss.org  Wed Dec  6 11:21:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4574) Upgrade Mojarra to 2.2.11
In-Reply-To: <JIRA.12570491.1430458454000@Atlassian.JIRA>
References: <JIRA.12570491.1430458454000@Atlassian.JIRA>
	<JIRA.12570491.1430458454000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570491.1430458454000.88739.1512577283351@Atlassian.JIRA>


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

Kabir Khan closed WFLY-4574.
----------------------------


> Upgrade Mojarra to 2.2.11
> -------------------------
>
>                 Key: WFLY-4574
>                 URL: https://issues.jboss.org/browse/WFLY-4574
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JSF
>    Affects Versions: 9.0.0.CR1
>            Reporter: Cody Lerum
>            Assignee: Farah Juma
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> Mojarra 2.2 now appears to be on a 4-6 month release cycle for 2.2.x and 2.2.11 is due for release on May 5th. https://java.net/jira/browse/JAVASERVERFACES/fixforversion/17193/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
> It would be great if we could get this updated before 9.1.0.Final.
> https://java.net/jira/browse/JAVASERVERFACES-3848 for example would be nice to pick up.



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

From issues at jboss.org  Wed Dec  6 11:21:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5342) Upgrade to Artemis
	1.1.0-wildfly-6
In-Reply-To: <JIRA.12584903.1442299840000@Atlassian.JIRA>
References: <JIRA.12584903.1442299840000@Atlassian.JIRA>
	<JIRA.12584903.1442299840000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584903.1442299840000.88744.1512577283447@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5342.
----------------------------


> Upgrade to Artemis 1.1.0-wildfly-6
> ----------------------------------
>
>                 Key: WFLY-5342
>                 URL: https://issues.jboss.org/browse/WFLY-5342
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>             Fix For: 10.0.0.CR1
>
>
> Upgrade to Artemis 1.1.0-wildfly-6 which removes ARTEMIS-210 feature from Artemis RA as it is creating failures in our test suite due to leaking JMS connections and sessions across RA's endpoints.
> https://github.com/apache/activemq-artemis/compare/1.1.0...wildfly:1.1.0-wildfly-6



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4566) Remove support for
 jboss-as-datasources_1_0.xsd
In-Reply-To: <JIRA.12570079.1430224921000@Atlassian.JIRA>
References: <JIRA.12570079.1430224921000@Atlassian.JIRA>
	<JIRA.12570079.1430224921000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570079.1430224921000.88748.1512577283518@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4566.
----------------------------


> Remove support for jboss-as-datasources_1_0.xsd
> -----------------------------------------------
>
>                 Key: WFLY-4566
>                 URL: https://issues.jboss.org/browse/WFLY-4566
>             Project: WildFly
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Alpha6
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4120) JAX-WS:
 HandlerChain-Annotation referencing file outside Java Archive causes
 JBAS015507
In-Reply-To: <JIRA.12558051.1416837531000@Atlassian.JIRA>
References: <JIRA.12558051.1416837531000@Atlassian.JIRA>
	<JIRA.12558051.1416837531000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558051.1416837531000.88754.1512577283672@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4120.
----------------------------


> JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-4120
>                 URL: https://issues.jboss.org/browse/WFLY-4120
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 8.2.0.Final
>         Environment: Windows 8.1
>            Reporter: Manfred Otte
>            Assignee: Alessio Soldano
>            Priority: Minor
>             Fix For: 10.0.0.Alpha3
>
>         Attachments: testjsr109.war
>
>
> Regarding JSR 109, chapter 6.3 the "handler chain file can also be packaged and specified in the annotation such that, it is accessible as a resource from the ClassPath. At runtime, container providers must first try to access the handler chain file as per the locations specified in JSR-181 specification. Failing that, they must try to access it as a resource from the ClassPath."
> The JBoss AS Documentation states that "The war is considered to be a single module, so classes defined in WEB-INF/lib are treated the same as classes in WEB-INF/classes. All classes packaged in the war will be loaded with the same class loader" (https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7).
> Following this statements I think it should be fine to have a HandlerChain-annnotated Webservice within a JAR inside a WAR (WEB-INF/lib) referencing a handler chain file that ist not part of the JAR but resides in WEB-INF/classes. However this situation results in 
> {code}
> Internal Server Error
> {
>     "outcome" => "failed",
>     "failure-description" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"testjsr109.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"testjsr109.war\".PARSE: JBAS018733: Failed to process phase PARSE of deployment \"testjsr109.war\"
>     Caused by: javax.xml.ws.WebServiceException: JBAS015507: Handler chain config file handlerchain.xml not found in ResourceRoot [root=\"/D:/tools/wildfly-8.2.0.Final/bin/content/testjsr109.war/WEB-INF/lib/testjsr109.jar\"]"}},
>     "rolled-back" => true
> }
> {code}
> The implementation of org.jboss.as.webservices.injection.WSHandlerChainAnnotationProcessor seems to expect, that the handler chain file is always part of the ResourceRoot the annotated WebService lives in. With respect to JSR 109 I think that this expectation is wrong and that a handler chain file outside the JAR is a valid scenario. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3518)
 JASPIAuthenticationMechanism#authenticate doesn't check if
 AuthenticatedSession is null
In-Reply-To: <JIRA.12544285.1403128819000@Atlassian.JIRA>
References: <JIRA.12544285.1403128819000@Atlassian.JIRA>
	<JIRA.12544285.1403128819000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544285.1403128819000.88766.1512577284005@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-3518.
----------------------------


> JASPIAuthenticationMechanism#authenticate doesn't check if AuthenticatedSession is null
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-3518
>                 URL: https://issues.jboss.org/browse/WFLY-3518
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.1.0.Final
>            Reporter: arjan tijms
>            Assignee: Stuart Douglas
>              Labels: jaspic
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> In {{org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism#authenticate}} the variable {{authSession}} in the fragment below is frequently null, leading to null pointer exceptions:
> {code}
>   if (sessionManager != null) {
>             AuthenticatedSessionManager.AuthenticatedSession authSession = sessionManager.lookupSession(exchange);
>             cachedAccount = authSession.getAccount(); // NPE HAPPENS HERE
>             // if there is a cached account we set it in the security context so that the principal is available to
>             // SAM modules via request.getUserPrincipal().
>             if (cachedAccount !=  null) {
>                 jaspicSecurityContext.setCachedAuthenticatedAccount(cachedAccount);
>             }
>         }
> {code}
> At another place in Undertow where {{AuthenticatedSession}} is used, there's an extra null check (See {{io.undertow.security.impl.CachedAuthenticatedSessionMechanism#runCached}}).
> I patched the code locally to add an extra null check:
> {code}
>         if (sessionManager != null) {
>             AuthenticatedSessionManager.AuthenticatedSession authSession = sessionManager.lookupSession(exchange);
>             cachedAccount = authSession == null? null : authSession.getAccount();
>             // if there is a cached account we set it in the security context so that the principal is available to
>             // SAM modules via request.getUserPrincipal().
>             if (cachedAccount !=  null) {
>                 jaspicSecurityContext.setCachedAuthenticatedAccount(cachedAccount);
>             }
>         }
> {code}
> After a short amount of testing everything seems to be okay with that extra check.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5050) JSP Cross-Context Include Not
	Working
In-Reply-To: <JIRA.12580180.1438619730000@Atlassian.JIRA>
References: <JIRA.12580180.1438619730000@Atlassian.JIRA>
	<JIRA.12580180.1438619730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580180.1438619730000.88773.1512577284211@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5050.
----------------------------


> JSP Cross-Context Include Not Working
> -------------------------------------
>
>                 Key: WFLY-5050
>                 URL: https://issues.jboss.org/browse/WFLY-5050
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.1.Final, 9.0.1.Final
>         Environment: Java 8
>            Reporter: Brett Prucha
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Beta1
>
>         Attachments: test.ear
>
>
> Including JSP files from a cross-context application results in various errors depending on how it's executed and which version of Wildfly (8 or 9) is being used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5004) Messaging migration does not
 work in domain mode
In-Reply-To: <JIRA.12579282.1437731991000@Atlassian.JIRA>
References: <JIRA.12579282.1437731991000@Atlassian.JIRA>
	<JIRA.12579282.1437731991000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579282.1437731991000.88778.1512577284383@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5004.
----------------------------


> Messaging migration does not work in domain mode
> ------------------------------------------------
>
>                 Key: WFLY-5004
>                 URL: https://issues.jboss.org/browse/WFLY-5004
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha6
>
>
> The :migrate operation of the legacy messaging subsystem does not work in domain mode. 
> The addresses returned by the describe handler starts with /subsystem while in domain mode, the subsystem configuration are under /profile=XXX
> The :migrate operation must prepend the operation parent address (EMPTY_ADDRESS in standalone mode, /profile=XXX in domain mode) for the operation to be successful.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4735) Example configuration
 standalone-hornetq-colocated.xml is not correct
In-Reply-To: <JIRA.12573724.1433335841000@Atlassian.JIRA>
References: <JIRA.12573724.1433335841000@Atlassian.JIRA>
	<JIRA.12573724.1433335841000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573724.1433335841000.88789.1512577284702@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4735.
----------------------------


>  Example configuration standalone-hornetq-colocated.xml is not correct
> ----------------------------------------------------------------------
>
>                 Key: WFLY-4735
>                 URL: https://issues.jboss.org/browse/WFLY-4735
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Marek Kopeck?
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> Example configuration standalone-hornetq-colocated.xml is not correct. This file is located in $JBOSS_HOME/docs/examples/configs
> Delete this file and replace it with correct configuration file for WildFly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 11:21:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4591) Memory leak
 inPerThreadTagHandlerPool | Wildfly 8.2.0.Final (Undertow)
In-Reply-To: <JIRA.12570814.1430897974000@Atlassian.JIRA>
References: <JIRA.12570814.1430897974000@Atlassian.JIRA>
	<JIRA.12570814.1430897974000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570814.1430897974000.88797.1512577284895@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4591.
----------------------------


> Memory leak inPerThreadTagHandlerPool | Wildfly 8.2.0.Final (Undertow)
> ----------------------------------------------------------------------
>
>                 Key: WFLY-4591
>                 URL: https://issues.jboss.org/browse/WFLY-4591
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>         Environment: CentOS release 6.5 (Final), java version "1.7.0_71" 64 bit VM, Wildfly 8.2.0.Final,  Min heap and Max heap 1536m
>  
>            Reporter: Srivathsan Agaram Venkatavaradhan
>            Assignee: Tomaz Cerar
>              Labels: garbage, jastow, undertow, wildfly
>             Fix For: 10.0.0.Alpha3
>
>         Attachments: jastow-2.0.0-SNAPSHOT.jar
>
>
> We upgraded from Jboss 7.1.1.Final to Wildfly 8.2.0.Final. After the upgrade we are seeing full frequent garbage collection (happening every 2 mins)  during load test.  This was not the case in Jboss 7.1.1.Final.  Our heap dumps suggested that there is huge memory leak with 
> org.apache.jasper.runtime.BodyContentImpl.  This is part of JSP runtime (jastow). On analysis we found that undertow uses default as PerThreadTagHanlderPool. By changing this to TagHanlderPool, this issue seems to vanish. 
> diff --git a/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java b/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java
> index eaa8560..c6c785f 100644
> --- a/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java
> +++ b/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java
> @@ -53,7 +53,7 @@ public class TagHandlerPool {
>                  result = null;
>              }
>          }
> -        if( result==null ) result=new PerThreadTagHandlerPool();
> +        if( result==null ) result=new TagHandlerPool();
>          result.init(config);
>  
>          return result;
> - See more at: https://developer.jboss.org/message/927538#927538
> I think this issue may be related to https://issues.jboss.org/browse/WFLY-4617  as there were huge garbage created and most of the contents were char array (rendered html). May be TagHanlderPool is creating more char instead of reusing from pool. Please provide thoughts. I can share, heapdump or MAT screenshots if needed.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4622) Add schema generator
 (com.sun.xml.bind:jaxb-jxc)
In-Reply-To: <JIRA.12571308.1431357125000@Atlassian.JIRA>
References: <JIRA.12571308.1431357125000@Atlassian.JIRA>
	<JIRA.12571308.1431357125000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571308.1431357125000.88416.1512577270461@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4622.
----------------------------


> Add schema generator (com.sun.xml.bind:jaxb-jxc)
> ------------------------------------------------
>
>                 Key: WFLY-4622
>                 URL: https://issues.jboss.org/browse/WFLY-4622
>             Project: WildFly
>          Issue Type: Task
>          Components: XML Frameworks
>    Affects Versions: 9.0.0.CR1
>            Reporter: Scott Marlow
>            Assignee: Tomaz Cerar
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> <dependency>
> 	<groupId>com.sun.xml.bind</groupId>
> 	<artifactId>jaxb-jxc</artifactId>
> 	<version>2.2.11</version>
> </dependency>



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5018) Undertow mod_cluster CLI:
 Control Node: Enable Contexts, Disable Contexts, Stop Contexts
In-Reply-To: <JIRA.12578744.1437479975000@Atlassian.JIRA>
References: <JIRA.12578744.1437479975000@Atlassian.JIRA>
	<JIRA.12578744.1437479975000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578744.1437479975000.88802.1512577285038@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5018.
----------------------------


> Undertow mod_cluster CLI: Control Node: Enable Contexts, Disable Contexts, Stop Contexts
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5018
>                 URL: https://issues.jboss.org/browse/WFLY-5018
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Michal Karm Babacek
>            Assignee: Stuart Douglas
>            Priority: Critical
>              Labels: mod_cluster
>             Fix For: 10.0.0.Beta1
>
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Control Nodes
> For any  Undertow mod_cluster proxy environment, it is essential to be able to Enable Contexts, Disable Contexts and Stop Contexts on a selected worker Node.
> It is an equivalent of sending this MCMP message attributes ({{worker-2}} is an arbitrary worker node's JVMRoute): 
> * Enable Contexts {{Cmd=ENABLE-APP&Range=NODE&JVMRoute=worker-2}}
> * Disable Contexts {{Cmd=DISABLE-APP&Range=NODE&JVMRoute=worker-2}}
> * Stop Contexts {{Cmd=STOP-APP&Range=NODE&JVMRoute=worker-2}}
> h3. Call to action
> Enable user to carry out these actions via WildFly CLI.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5241) Update messaging subsystem
 descriptions to properly report path cardinality
In-Reply-To: <JIRA.12583339.1441046973000@Atlassian.JIRA>
References: <JIRA.12583339.1441046973000@Atlassian.JIRA>
	<JIRA.12583339.1441046973000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583339.1441046973000.88807.1512577285146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5241.
----------------------------


> Update messaging subsystem descriptions to properly report path cardinality
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-5241
>                 URL: https://issues.jboss.org/browse/WFLY-5241
>             Project: WildFly
>          Issue Type: Task
>          Components: JMS
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 10.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY10/Description+of+the+Management+Model has been updated to more intelligently report cardinality information about resource registrations, with each reg reporting its own cardinality instead of having the parent report data about the "key" portion of potentially unrelated children.
> The two messaging subsystems are actually trying to use the old way for "path" children, so this JIRA is to move to the new way.
> Instead of the parent resource reporting there must be 4 and no more than 4 children with key "path", now each of the 4 valid path children types will report that the min-occurs of that type is 1. (The max-occurs is also 1, but that will not be reported as that, per the spec, is the default for a 'singleton' type, and each of the 4 path types is a singleton.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4981) Upgrade JBossWS from
 5.0.0.Final to 5.1.0.Beta1
In-Reply-To: <JIRA.12578797.1437492459000@Atlassian.JIRA>
References: <JIRA.12578797.1437492459000@Atlassian.JIRA>
	<JIRA.12578797.1437492459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578797.1437492459000.88811.1512577285300@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4981.
----------------------------


> Upgrade JBossWS from 5.0.0.Final to 5.1.0.Beta1
> -----------------------------------------------
>
>                 Key: WFLY-4981
>                 URL: https://issues.jboss.org/browse/WFLY-4981
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4676) Unify help message in
 wsprovide.bat and wsprovide.sh
In-Reply-To: <JIRA.12572645.1432628826000@Atlassian.JIRA>
References: <JIRA.12572645.1432628826000@Atlassian.JIRA>
	<JIRA.12572645.1432628826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572645.1432628826000.88816.1512577285397@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4676.
----------------------------


> Unify help message in wsprovide.bat and wsprovide.sh
> ----------------------------------------------------
>
>                 Key: WFLY-4676
>                 URL: https://issues.jboss.org/browse/WFLY-4676
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Marek Kopeck?
>            Assignee: Alessio Soldano
>            Priority: Minor
>             Fix For: 10.0.0.Alpha3
>
>
> Description of problem:
> Unify help message in wsprovide.bat and wsprovide.sh
> Steps to Reproduce:
> 1. On windows: wsconsume.bat -h
> 2. On linux: wsconsume.sh -h
> Actual results:
> On windows:
> ...
> usage: WSProvide [options] <endpoint class name>
> ...
> On linux:
> ...
> usage: wsprovide.sh [options] <endpoint class name>
> ...
> Expected results on Windows:
> ...
> usage: wsprovide.bat [options] <endpoint class name>
> ...



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 11:21:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2667) Support application-level
 batch configuration
In-Reply-To: <JIRA.12528176.1387392969000@Atlassian.JIRA>
References: <JIRA.12528176.1387392969000@Atlassian.JIRA>
	<JIRA.12528176.1387392969000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528176.1387392969000.88821.1512577285537@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-2667.
----------------------------


> Support application-level batch configuration
> ---------------------------------------------
>
>                 Key: WFLY-2667
>                 URL: https://issues.jboss.org/browse/WFLY-2667
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Batch
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Cheng Fang
>            Assignee: James Perkins
>             Fix For: 10.0.0.Alpha1
>
>
> Applications should be able to override certain batch configuration in WildFly batch subsystem with application deployment descriptors.  In particular, applications may want to specify their own datasource jndi-name for batch job repository.  



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4680) Fork and JChannel names need
	to be unique
In-Reply-To: <JIRA.12572864.1432676755000@Atlassian.JIRA>
References: <JIRA.12572864.1432676755000@Atlassian.JIRA>
	<JIRA.12572864.1432676755000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572864.1432676755000.88825.1512577285689@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4680.
----------------------------


> Fork and JChannel names need to be unique
> -----------------------------------------
>
>                 Key: WFLY-4680
>                 URL: https://issues.jboss.org/browse/WFLY-4680
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> The point is to
> * recreate the channels as ee-web (with web fork on it) instead of channel web with fork web on it
> * also investigate why without the fix for https://issues.jboss.org/browse/WFLY-4435 (and WFLY-4680) naming fork channels and jchannels the same (e.g. web) doesn't just result in duplicated service warning, but instead fails badly e.g. NPE in Infinispan https://issues.jboss.org/browse/ISPN-5483



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5285) Remove use of
 ManagementResourceRegistration.setRuntimeOnly()
In-Reply-To: <JIRA.12584088.1441455141000@Atlassian.JIRA>
References: <JIRA.12584088.1441455141000@Atlassian.JIRA>
	<JIRA.12584088.1441455141000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584088.1441455141000.88829.1512577285768@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5285.
----------------------------


> Remove use of ManagementResourceRegistration.setRuntimeOnly()
> -------------------------------------------------------------
>
>                 Key: WFLY-5285
>                 URL: https://issues.jboss.org/browse/WFLY-5285
>             Project: WildFly
>          Issue Type: Task
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 10.0.0.CR1
>
>
> Replace use of to-be-deprecated ManagementResourceRegistration.setRuntimeOnly() with setting this up via the ResourceDefinition.
> Right thing to do, plus it blocks WFCORE-959.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4587) Provide a migration
 management operation for HornetQ to ActiveMQ Artemis
In-Reply-To: <JIRA.12570691.1430816653000@Atlassian.JIRA>
References: <JIRA.12570691.1430816653000@Atlassian.JIRA>
	<JIRA.12570691.1430816653000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570691.1430816653000.88833.1512577285881@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4587.
----------------------------


> Provide a migration management operation for HornetQ to ActiveMQ Artemis
> ------------------------------------------------------------------------
>
>                 Key: WFLY-4587
>                 URL: https://issues.jboss.org/browse/WFLY-4587
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha6
>
>
> WildFly 10 has a new messaging-activemq subsystem using ActiveMQ Artemis as its messaging broker.
> WildFly 10 needs to provide a :migrate management operation so that user upgrading from WildFly 9 to 10 can start WildFly 10 with their old configuration (which used HornetQ) and migrate to the new subsystem (which used ActiveMQ Artemis).
> This migrate operation deals only with the management resource and does *not* migrate data from HornetQ to Artemis. This will done in a separate step (using either a JMS bridge or data export tool)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3671) picketlink-deltaspike is
	missing
In-Reply-To: <JIRA.12547591.1406548940000@Atlassian.JIRA>
References: <JIRA.12547591.1406548940000@Atlassian.JIRA>
	<JIRA.12547591.1406548940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547591.1406548940000.88845.1512577286320@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-3671.
----------------------------


> picketlink-deltaspike is missing
> --------------------------------
>
>                 Key: WFLY-3671
>                 URL: https://issues.jboss.org/browse/WFLY-3671
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Juergen Zimmermann
>            Assignee: Pedro Igor
>             Fix For: 10.0.0.Alpha1
>
>
> I'm using the current snapshot of WFLY 9.0.0.Alpha1. However, there is no picketlink-deltaspike.jar in the modules/system/layers/base directory. This JAR contains the CDI interceptor for PicketLink.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5246) Upgrade RESTEasy to
	3.0.12.Final
In-Reply-To: <JIRA.12583367.1441088395000@Atlassian.JIRA>
References: <JIRA.12583367.1441088395000@Atlassian.JIRA>
	<JIRA.12583367.1441088395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583367.1441088395000.88850.1512577286461@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5246.
----------------------------


> Upgrade RESTEasy to 3.0.12.Final
> --------------------------------
>
>                 Key: WFLY-5246
>                 URL: https://issues.jboss.org/browse/WFLY-5246
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: REST
>            Reporter: Weinan Li
>            Assignee: Weinan Li
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5092) Can't start server in
 --admin-only with EAP 6.4 configuration
In-Reply-To: <JIRA.12581008.1439390511000@Atlassian.JIRA>
References: <JIRA.12581008.1439390511000@Atlassian.JIRA>
	<JIRA.12581008.1439390511000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581008.1439390511000.88859.1512577286668@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5092.
----------------------------


> Can't start server in --admin-only with EAP 6.4 configuration
> -------------------------------------------------------------
>
>                 Key: WFLY-5092
>                 URL: https://issues.jboss.org/browse/WFLY-5092
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 10.0.0.Beta2
>
>
> When starting WildFly 10.0.0.Beta1 in {{--admin-only}} mode to perform {{:migrate}} operations on old subsystems, using an unmodified {{standalone-full-ha.xml}} configuration file from EAP 6.4.0, I'm getting errors.
> Based on http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004306.html, I'm expecting that I don't have to perform any changes to the EAP 6.4 configuration file, yet in order to successfully boot the new server with the old configuration file, I have to perform the following set of changes:
> - remove the {{cmp}}, {{jaxr}} and {{threads}} extensions and subsystems (this seems to be already covered by WFCORE-875)
> - copy the entire configuration of the {{ejb3}} subsystem (version 3.0) from a new {{standalone-full-ha.xml}} to the old one, because I'm not able to fix the old subsystem (version 1.5) from the error message \[1\]
> - add the {{io}} extension and subsystem from a new {{standalone-full-ha.xml}} to the old one, because {{remoting}} needs it to boot \[2\]
> \[1\] {code}16:31:35,167 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: "WFLYEJB0451: Attribute 'default-clustered-sfsb-cache' is not supported on current version servers; it is only allowed if its value matches 'default-sfsb-cache'"{code}
> \[2\] {code}16:34:35,376 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=remoting' are not available:
>     org.wildfly.io.worker.default
> {code}
> In http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004303.html, I also mentioned {{datasources}}, but that was a false alarm -- that was from normal server boot, not {{--admin-only}}, and hence invalid.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4860) Update examples to use the
 messaging-activemq subsystem
In-Reply-To: <JIRA.12576887.1435838638000@Atlassian.JIRA>
References: <JIRA.12576887.1435838638000@Atlassian.JIRA>
	<JIRA.12576887.1435838638000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576887.1435838638000.88864.1512577286812@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4860.
----------------------------


> Update examples to use the messaging-activemq subsystem
> -------------------------------------------------------
>
>                 Key: WFLY-4860
>                 URL: https://issues.jboss.org/browse/WFLY-4860
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> Update all examples shipped with WildFly to use the messaging-activemq subsystem instead of the legacy messaging subsystem.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4825) Add capabilities and
 requirements for data sources
In-Reply-To: <JIRA.12576065.1435078434000@Atlassian.JIRA>
References: <JIRA.12576065.1435078434000@Atlassian.JIRA>
	<JIRA.12576065.1435078434000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576065.1435078434000.88867.1512577286908@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4825.
----------------------------


> Add capabilities and requirements for data sources
> --------------------------------------------------
>
>                 Key: WFLY-4825
>                 URL: https://issues.jboss.org/browse/WFLY-4825
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JCA
>            Reporter: James Perkins
>            Assignee: James Perkins
>              Labels: affects_elytron
>             Fix For: 10.0.0.Alpha6
>
>
> Add capabilities and requirements support to data-sources.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4601) Upgrade Infinispan to
 7.2.1.Final and Hibernate Search to 5.2.0.Final
In-Reply-To: <JIRA.12570942.1430951018000@Atlassian.JIRA>
References: <JIRA.12570942.1430951018000@Atlassian.JIRA>
	<JIRA.12570942.1430951018000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570942.1430951018000.88873.1512577287020@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4601.
----------------------------


> Upgrade Infinispan to 7.2.1.Final and Hibernate Search to 5.2.0.Final
> ---------------------------------------------------------------------
>
>                 Key: WFLY-4601
>                 URL: https://issues.jboss.org/browse/WFLY-4601
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> Also, brings hibernate-search up to 5.2.0.Final.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4578) Consolidate attribute types
 in new IIOP subsystem
In-Reply-To: <JIRA.12570561.1430724634000@Atlassian.JIRA>
References: <JIRA.12570561.1430724634000@Atlassian.JIRA>
	<JIRA.12570561.1430724634000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570561.1430724634000.88879.1512577287211@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4578.
----------------------------


> Consolidate attribute types in new IIOP subsystem
> -------------------------------------------------
>
>                 Key: WFLY-4578
>                 URL: https://issues.jboss.org/browse/WFLY-4578
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>            Reporter: Harald Pehl
>            Assignee: Tomasz Adamski
>            Priority: Critical
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> Some attribute types like "export-corbaloc" are booleans, but are described as strings with allowed values ["true", "false"]. Please use model type boolean for these attributes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5299) WFLYWELD0001 and WFLYWELD0002
 errors deploying helloworld-mbean quickstart
In-Reply-To: <JIRA.12584323.1441763198000@Atlassian.JIRA>
References: <JIRA.12584323.1441763198000@Atlassian.JIRA>
	<JIRA.12584323.1441763198000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584323.1441763198000.88884.1512577287314@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5299.
----------------------------


> WFLYWELD0001 and WFLYWELD0002 errors deploying helloworld-mbean quickstart
> --------------------------------------------------------------------------
>
>                 Key: WFLY-5299
>                 URL: https://issues.jboss.org/browse/WFLY-5299
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Sande Gilda
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>
> When deploying helloworld-mbean QS, WFLYWELD0001 and WFLYWELD0002 error messages are logged in server log:
> {code}
> ERROR [org.jboss.as.weld] (ServerService Thread Pool -- 58) WFLYWELD0001: Failed to setup Weld contexts: javax.naming.NameNotFoundException: BeanManager -- service jboss.naming.context.java.module."jboss-helloworld-mbean-helloworld-mbean-service.sar"."jboss-helloworld-mbean-helloworld-mbean-service.sar".BeanManager
> ERROR [org.jboss.as.weld] (ServerService Thread Pool -- 58) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: BeanManager -- service jboss.naming.context.java.module."jboss-helloworld-mbean-helloworld-mbean-service.sar"."jboss-helloworld-mbean-helloworld-mbean-service.sar".BeanManager
> {code}
> [~jharting] said: 
>         The problem is triggered by this change: https://github.com/wildfly/wildfly/commit/20bbfce9f972c73ed1c3ba250ad3f15aa0f32d96
>         I am not sure why WeldContextSetup is being called for each AbstractService.invokeLifecycleMethod(). Looks like either WeldContextSetup should not be added to this particular list of setup actions or a wrong list of setup actions is used by AbstractService.
> See this issue for details: https://issues.jboss.org/browse/JBEAP-625



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4781) Add 'disabled-methods'
 attribute to the listeners
In-Reply-To: <JIRA.12574904.1434268762000@Atlassian.JIRA>
References: <JIRA.12574904.1434268762000@Atlassian.JIRA>
	<JIRA.12574904.1434268762000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574904.1434268762000.88888.1512577287469@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4781.
----------------------------


> Add 'disabled-methods' attribute to the listeners
> -------------------------------------------------
>
>                 Key: WFLY-4781
>                 URL: https://issues.jboss.org/browse/WFLY-4781
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha5
>
>
> This will allow some methods (such as TRACE) to be disabled by default



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5199) On MariaDB 5.3+ and MySQL
 5.6.4+,
 EJB timers in a JDBC storage don't work correctly due to timestamp rounding
In-Reply-To: <JIRA.12582554.1440513294000@Atlassian.JIRA>
References: <JIRA.12582554.1440513294000@Atlassian.JIRA>
	<JIRA.12582554.1440513294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582554.1440513294000.88892.1512577287656@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5199.
----------------------------


> On MariaDB 5.3+ and MySQL 5.6.4+, EJB timers in a JDBC storage don't work correctly due to timestamp rounding
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5199
>                 URL: https://issues.jboss.org/browse/WFLY-5199
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Beta2
>         Environment: MariaDB 5.3+, Mysql 5.6.4+
>            Reporter: Jan Martiska
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>
> EJB timers don't execute, because the DatabaseTimerPersistence.shouldRun method returns false for them, because it is unable to SELECT them from the database using a java.sql.Timestamp.
> On MariaDB 5.3+ and MySQL 5.6.4+, the behavior of the DATETIME type has changed compared to MySQL 5.5 and older.
> In previous versions, it was possible to insert into DATETIME columns with JDBC using a java.sql.Timestamp which contained fractional seconds, the fraction was truncated/rounded and a subsequent SELECT statement with the same java.sql.Timestamp returned such rows, because the fraction was truncated/rounded from the queried Timestamp too.
> On MySQL 5.6.4+ and MariaDB 5.3+, when a java.sql.Timestamp including a fractional second is inserted into a DATETIME, attempting to SELECT with the same Timestamp doesn't return the row, because the DATETIME type now defaults to DATETIME(0) which truncates/rounds to whole seconds, and the queried Timestamp no longer gets truncated/rounded during the query execution. It would only work if the column was declared as DATETIME(6), which ensures that inserted values don't get truncated/rounded. Documentation: https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html
> MySQL rounds the timestamp, MariaDB truncates it (always rounds down).
> However, declaring DATETIME(6) is not possible in older versions of MySQL or MariaDB, so to support both new and old versions, we have probably these options:
> 1. introduce a new DDL file(s) for MySQL 5.6.4+ and MariaDB 5.3+ and use it depending on the detected version - this DDL would use DATETIME(6) instead of DATETIME
> 2. change the DatabaseTimerPersistence implementation so that it will not insert fractional seconds into the database at all (EJB timers don't support timing with higher precision than whole seconds anyway)
> 3. same as option 2, but only for MariaDB/MySQL dialects 
> 4. any other idea?
> I personally like number 3 the best, it is the least risky and introduces only minimal changes.. but it's still somewhat ugly.
> This seems to resolve it for me (implementation suggestion of option 3): https://github.com/jmartisk/wildfly/commits/mysql-mariadb-timer-suggestion



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4445) Remove "path" and
 "relative-to" attributes from CLI from transactions subsystem
In-Reply-To: <JIRA.12566321.1426764216000@Atlassian.JIRA>
References: <JIRA.12566321.1426764216000@Atlassian.JIRA>
	<JIRA.12566321.1426764216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566321.1426764216000.88900.1512577287824@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4445.
----------------------------


> Remove "path" and "relative-to" attributes from CLI from transactions subsystem
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-4445
>                 URL: https://issues.jboss.org/browse/WFLY-4445
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Transactions
>            Reporter: Ondra Chaloupka
>            Assignee: Amos Feng
>             Fix For: 10.0.0.Alpha6
>
>
> As "process-id/file" functionality is not yet added in EAP, the "path" and "relative-to" attributes are useless in transactions subsystem of CLI.
> Please remove them.
> Also please remove them from "jboss-as-txn***.xsd" file as well.
> For detailed discussion please refer to https://bugzilla.redhat.com/show_bug.cgi?id=1039081



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4597) Remove classname Strings from
 XTS subsystem
In-Reply-To: <JIRA.12497218.1374652000000@Atlassian.JIRA>
References: <JIRA.12497218.1374652000000@Atlassian.JIRA>
	<JIRA.12497218.1374652000000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497218.1374652000000.88906.1512577288028@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4597.
----------------------------


> Remove classname Strings from XTS subsystem
> -------------------------------------------
>
>                 Key: WFLY-4597
>                 URL: https://issues.jboss.org/browse/WFLY-4597
>             Project: WildFly
>          Issue Type: Task
>          Components: XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 10.0.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> THe XTS SubSystem has many classnames passed to Jandex as raw Strings. It would be better to use Class#getName as it is type-safe. 
> When this code was written, this was not possible, due to the nature of the order in which class-loading was done and the fact that the code in question was executed very early in the server boot. I don't remember the specific details.
> However, something seems to have changed in WildFly, such that we can now use Class#getName on the classes we require. This issue it to replace all the classname Strings with Class#getName() and to also simplify the code under org.jboss.as.xts.jandex, as a lot of that verbose code was added to to cope with the limitation of not being able to use Class#getName().



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4581) Provide a migration
 management operation for JacORB to OpenJDKOrb
In-Reply-To: <JIRA.12570623.1430752738000@Atlassian.JIRA>
References: <JIRA.12570623.1430752738000@Atlassian.JIRA>
	<JIRA.12570623.1430752738000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570623.1430752738000.88912.1512577288254@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4581.
----------------------------


> Provide a migration management operation for JacORB to OpenJDKOrb 
> ------------------------------------------------------------------
>
>                 Key: WFLY-4581
>                 URL: https://issues.jboss.org/browse/WFLY-4581
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: IIOP
>    Affects Versions: 9.0.0.CR1
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.Alpha5
>
>
> Provide a management operation that performs a one-time conversion from the JacORB subsystem into the JDK Orb subsystem. This allows users using the CLI to perform a migration, as well as tools such as WindUp to also execute the change.
> Alternatively emulation of JacORB, using JDK Orb underneath, if viable, could be performed.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5043) Undertow mod_cluster CLI:
 Display node's Elected, Read, Transferred, Connected stats
In-Reply-To: <JIRA.12578741.1437479972000@Atlassian.JIRA>
References: <JIRA.12578741.1437479972000@Atlassian.JIRA>
	<JIRA.12578741.1437479972000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578741.1437479972000.88916.1512577288333@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5043.
----------------------------


> Undertow mod_cluster CLI: Display node's Elected, Read, Transferred, Connected stats
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-5043
>                 URL: https://issues.jboss.org/browse/WFLY-5043
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Michal Karm Babacek
>            Assignee: Stuart Douglas
>              Labels: mod_cluster
>             Fix For: 10.0.0.Beta1
>
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Implement & Display node's Elected, Read, Transferred and Connected stats
> At the moment, this is all there is to see:
> {noformat}
> "balancer" => {
>     "qa_balancer" => {"node" => {"worker-2" => {
>         "load" => 89,
>         "status" => "NODE_UP",
>         "context" => {"/clusterbench" => {
>             "requests" => 0,
>             "status" => "enabled"
>         }}
>     }}},
> ...
> {noformat}
> Furthermore, at a glance, it appears that a part of the needed stats is a mere placeholder at the moment: [NodeStats.java|https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/proxy/mod_cluster/NodeStats.java]
> h3. Call to action
> Display the aforementioned stats for each node. Let me set priorities according to what is really used in the battlefield:
>  * {color:red}Critical{color}: *Elected* (it is often correlated with *Load* during load metric *history* and *capacity* tuning)
>  * {color:green}Minor{color}: *Read*
>  * {color:green}Minor{color}: *Transferred*
>  * {color:green}Minor{color}: *Connected*



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4999) XSiteBackupForTestCase tests
 fail on Windows with IPv6
In-Reply-To: <JIRA.12579206.1437669543000@Atlassian.JIRA>
References: <JIRA.12579206.1437669543000@Atlassian.JIRA>
	<JIRA.12579206.1437669543000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579206.1437669543000.88922.1512577288451@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4999.
----------------------------


> XSiteBackupForTestCase tests fail on Windows with IPv6
> ------------------------------------------------------
>
>                 Key: WFLY-4999
>                 URL: https://issues.jboss.org/browse/WFLY-4999
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: James Perkins
>            Assignee: Radoslav Husar
>              Labels: testsuite_stability
>             Fix For: 10.0.0.Beta1
>
>
> See http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF_PullRequest&testNameId=1140899232324454378&tab=testDetails



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5224) Unable to read resource after
 changing process-id-* in transactions subsystem
In-Reply-To: <JIRA.12583016.1440683765000@Atlassian.JIRA>
References: <JIRA.12583016.1440683765000@Atlassian.JIRA>
	<JIRA.12583016.1440683765000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583016.1440683765000.88930.1512577288636@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5224.
----------------------------


> Unable to read resource after changing process-id-* in transactions subsystem
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-5224
>                 URL: https://issues.jboss.org/browse/WFLY-5224
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Harald Pehl
>            Assignee: Stefano Maestri
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> After switching between {{process-id-uuid}} and {{process-id-socket-bindings}} as described in WFLY-2623 a follow-up {{/subsystem=transactions:read-resource}} fails until the server / host is reloaded. 
> The resource should be readable and return an {{reload-required}} header. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4864) JSP in web application
 doesn't get VFS-based security permissions
In-Reply-To: <JIRA.12576930.1435852916000@Atlassian.JIRA>
References: <JIRA.12576930.1435852916000@Atlassian.JIRA>
	<JIRA.12576930.1435852916000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576930.1435852916000.88937.1512577288772@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4864.
----------------------------


> JSP in web application doesn't get VFS-based security permissions
> -----------------------------------------------------------------
>
>                 Key: WFLY-4864
>                 URL: https://issues.jboss.org/browse/WFLY-4864
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Bartosz Spyrko-?mietanko
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Alpha6
>
>         Attachments: read-props.war, security.policy
>
>
> Permissions granted to web applications (using vfs:/... codebase) are not available in JSPs.
> After deploying the test app, a call to http://localhost:8080/read-props/ gives following error:
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "java.home" "read")" in code source "(file:/Users/spyrkob/workspaces/set/servers/wildfly-10.x/wildfly-10.0.0.Alpha5-SNAPSHOT/standalone/tmp/read-props.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader at 3cae09bb")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:270)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:493)
> 	at java.lang.System.getProperty(System.java:714)
> 	at org.apache.jsp.index_jsp._jspService(index_jsp.java:95)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> 	... 33 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 11:21:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4751) JNDI lookups of JMS
 topics/queues can lead to null return values due to a missing service
 dependency
In-Reply-To: <JIRA.12574122.1433603817000@Atlassian.JIRA>
References: <JIRA.12574122.1433603817000@Atlassian.JIRA>
	<JIRA.12574122.1433603817000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574122.1433603817000.88944.1512577288906@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4751.
----------------------------


> JNDI lookups of JMS topics/queues can lead to null return values due to a missing service dependency
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4751
>                 URL: https://issues.jboss.org/browse/WFLY-4751
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> The HornetQ subsystem allows for defining jms-topic(s) and jms-queus(s) for a hornetq-server. The jms-topic(s) and jms-queue(s) allow for JNDI names to be specified for each of those JMS destinations. For each of these jms-topic(s) and jms-queues(s) the HornetQ subsystem does the following:
> 	- Set up JMSTopicService and JMSQueueService depending on the destination type.
> 		- These services in their start method use HornetQ APIs to create the destinations. Note that JNDI binding of these destinations is *not*
> 			done at this point via the HornetQ APIs and instead (is rightly) left for the (WildFly) BinderService(s) to take care off.
> 		- The getValue() method of these services return the Topic/Queue that was created by the services' start using HornetQ API
> 	
> 	- For each of the destinations, the HornetQ subsystem sets up a BinderService each for the JNDI names specified for those destinations. The BinderService is configured to fetch the bound value via the JMSTopicService/JMSQueueService (i.e. they use ValueManagedReferenceFactory which ultimately ends up in a call to getValue() of those services).
>  Looks fine, except that the BinderService(s) have *not* been setup to "depend" on the JMSTopicService/JMSQueueService.
>  As a result, in theory (and I suspect in reality here https://developer.jboss.org/thread/259981?start=0&tstart=0) JNDI lookups for the topic/queue (even when proper dependencies are setup between the deployments and the BinderService) can end up returning null values, since although the BinderService is up and running, the backing JMSTopicService or JMSQueueService which are responsible for providing the bound value are not yet started and the topic/queue hasn't yet been created.
> P.S: I don't have a way to reproduce this, since it all depends on the service startup timings. I however do suspect that this is what is causing those issues in that thread. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4766) Filter matching static
 resource confuses servlet matching logic
In-Reply-To: <JIRA.12574657.1434023759000@Atlassian.JIRA>
References: <JIRA.12574657.1434023759000@Atlassian.JIRA>
	<JIRA.12574657.1434023759000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574657.1434023759000.88948.1512577288977@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4766.
----------------------------


> Filter matching static resource confuses servlet matching logic
> ---------------------------------------------------------------
>
>                 Key: WFLY-4766
>                 URL: https://issues.jboss.org/browse/WFLY-4766
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.CR2, 10.0.0.Alpha2
>            Reporter: Peter Major
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.Final, 10.0.0.Beta1
>
>         Attachments: hello.war
>
>
> Imagine the following setup:
> * There are static files stored under the servlet context in the helloworld folder
> * there is a servlet mapped to /hello/*
> * there is a filter configured to match /helloworld/index.html
> For some reason with this set up the end result is that when I request /helloworld or /helloworld/index.html then the servlet is displayed instead of my static files (note that welcome-file-list was configured for index.html). As /hello/* *really* shouldn't match /helloworld I can only think that this is a bug in wildfly, possibly somewhere in undertow.
> Oddly enough, once the filter mapping is removed, suddenly the static file is served correctly, so the filter must have some role in this issue.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4754) NPE is thrown if @LocalBean
 is used on a WebService
In-Reply-To: <JIRA.12574160.1433757636000@Atlassian.JIRA>
References: <JIRA.12574160.1433757636000@Atlassian.JIRA>
	<JIRA.12574160.1433757636000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574160.1433757636000.88952.1512577289072@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4754.
----------------------------


> NPE is thrown if @LocalBean is used on a WebService
> ---------------------------------------------------
>
>                 Key: WFLY-4754
>                 URL: https://issues.jboss.org/browse/WFLY-4754
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.0.Final, 9.0.0.CR1
>            Reporter: Dmitry Lisovsky
>             Fix For: 10.0.0.Alpha4
>
>
> If you create a WebService without interface and use @LocalBean on it, during deploy you get:
> (stacktrace for 9 CR1)
> {noformat}
> 15:26:18,439 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."mms.ear"."rvm.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."mms.ear"."rvm.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "rvm.jar" of deployment "mms.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> 	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:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEE0024: Could not configure component ReviewManagerSoapService
> 	at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:95)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.security.EJBSecurityViewConfigurator.handlePermissions(EJBSecurityViewConfigurator.java:215)
> 	at org.jboss.as.ejb3.security.EJBSecurityViewConfigurator.configure(EJBSecurityViewConfigurator.java:123)
> 	at org.jboss.as.ee.component.DefaultComponentViewConfigurator.configure(DefaultComponentViewConfigurator.java:67)
> 	at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:81)
> 	... 6 more
> {noformat}
> The same issue in EAP: JBEAP-66



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4943) jboss.ws.config in appclient
 should not require the Undertow subsystem
In-Reply-To: <JIRA.12578301.1437058956000@Atlassian.JIRA>
References: <JIRA.12578301.1437058956000@Atlassian.JIRA>
	<JIRA.12578301.1437058956000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578301.1437058956000.88958.1512577289222@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4943.
----------------------------


> jboss.ws.config in appclient should not require the Undertow subsystem
> ----------------------------------------------------------------------
>
>                 Key: WFLY-4943
>                 URL: https://issues.jboss.org/browse/WFLY-4943
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Services
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Scott Marlow
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Alpha6
>
>
> Do the same as we do with JMX subsystem, that is checking if the undertow subsystem is declared as a child of the resources root and using the information to decide on adding the REQUIRED dependency or not. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4592) Deprecate messaging subsystem
In-Reply-To: <JIRA.12570825.1430903060000@Atlassian.JIRA>
References: <JIRA.12570825.1430903060000@Atlassian.JIRA>
	<JIRA.12570825.1430903060000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570825.1430903060000.88963.1512577289359@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4592.
----------------------------


> Deprecate messaging subsystem
> -----------------------------
>
>                 Key: WFLY-4592
>                 URL: https://issues.jboss.org/browse/WFLY-4592
>             Project: WildFly
>          Issue Type: Task
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> WildFly 10 will have a new messaging-activemq subsystem to provide its messaging capability.
> The current messaging subsystem is deprecated. It will be moved to legacy directory and all its runtime will be removed.
> Its management model will be preserved.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5207) Timestamp rounding issues on
 Microsoft SQL Server
In-Reply-To: <JIRA.12582641.1440584740000@Atlassian.JIRA>
References: <JIRA.12582641.1440584740000@Atlassian.JIRA>
	<JIRA.12582641.1440584740000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582641.1440584740000.88966.1512577289458@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5207.
----------------------------


> Timestamp rounding issues on Microsoft SQL Server
> -------------------------------------------------
>
>                 Key: WFLY-5207
>                 URL: https://issues.jboss.org/browse/WFLY-5207
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Beta2
>         Environment: all supported Microsoft SQL Server  versions (2008, 2012, 2014)
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>
> The DATETIME datatype in SQL Server has a precision of ~0.003 seconds.
> It sometimes can happen that an EJB timer gets scheduled to a timestamp which will get rounded after its insertion into the database, because the timestamps are generated with precision to miliseconds.
> After that, the timer service will be unable to locate this row, because it attempts to select using WHERE NEXT_DATE=$timestamp, where $timestamp is the original unrounded java.sql.Timestamp, and this condition no longer holds true. 
> After a timer is scheduled to go off at such unfortunate timestamp, it will never go off again.
> The solution is to either truncate the milisecond part, or to use the newer DATETIME2 datatype, which has an accuracy of 100 nanoseconds (https://msdn.microsoft.com/en-us/library/bb677335.aspx). DATETIME2 is supported on SQL Server 2008+.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5000) Undertow mod_cluster CLI:
 Control Context: Disable Stop
In-Reply-To: <JIRA.12578743.1437479974000@Atlassian.JIRA>
References: <JIRA.12578743.1437479974000@Atlassian.JIRA>
	<JIRA.12578743.1437479974000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578743.1437479974000.88783.1512577284506@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5000.
----------------------------


> Undertow mod_cluster CLI: Control Context: Disable Stop
> -------------------------------------------------------
>
>                 Key: WFLY-5000
>                 URL: https://issues.jboss.org/browse/WFLY-5000
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Michal Karm Babacek
>            Assignee: Stuart Douglas
>            Priority: Critical
>              Labels: mod_cluster
>             Fix For: 10.0.0.Beta1
>
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Control Contexts
> For any  Undertow mod_cluster proxy environment, it is essential to be able to Enable, Disable and Stop a particular Context on a selected worker Node.
> It is an equivalent of sending the following MCMP message attributes. Note that the command depends on {{JVMRoute}} - for a Node selction and on an {{Alias}} - for one of the Aliases a particular {{Context}} is configured with.
> * Enable context {{Cmd=ENABLE-APP&Range=CONTEXT&JVMRoute=worker-2&Alias=karm.brq.redhat.com&Context=/clusterbench}}
> * Disable context {{Cmd=DISABLE-APP&Range=CONTEXT&JVMRoute=worker-2&Alias=karm.brq.redhat.com&Context=/clusterbench}}
> * Stop context {{Cmd=STOP-APP&Range=CONTEXT&JVMRoute=worker-2&Alias=karm.brq.redhat.com&Context=/clusterbench}}
> h3. Call to action
> Enable user to carry out these actions via WildFly CLI.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5326) Upgrade Infinispan to
	8.0.1.Final
In-Reply-To: <JIRA.12584683.1441976026000@Atlassian.JIRA>
References: <JIRA.12584683.1441976026000@Atlassian.JIRA>
	<JIRA.12584683.1441976026000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584683.1441976026000.88972.1512577289581@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5326.
----------------------------


> Upgrade Infinispan to 8.0.1.Final
> ---------------------------------
>
>                 Key: WFLY-5326
>                 URL: https://issues.jboss.org/browse/WFLY-5326
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>              Labels: clustering_performance
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4893) Upgrade HAL to 2.8.1
In-Reply-To: <JIRA.12577552.1436446964000@Atlassian.JIRA>
References: <JIRA.12577552.1436446964000@Atlassian.JIRA>
	<JIRA.12577552.1436446964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577552.1436446964000.88974.1512577289623@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4893.
----------------------------


> Upgrade HAL to 2.8.1
> --------------------
>
>                 Key: WFLY-4893
>                 URL: https://issues.jboss.org/browse/WFLY-4893
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.Alpha5
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4408) WFLY-2160 fix did not include
 transformation
In-Reply-To: <JIRA.12564958.1425573024000@Atlassian.JIRA>
References: <JIRA.12564958.1425573024000@Atlassian.JIRA>
	<JIRA.12564958.1425573024000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564958.1425573024000.88978.1512577289698@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4408.
----------------------------


> WFLY-2160 fix did not include transformation
> --------------------------------------------
>
>                 Key: WFLY-4408
>                 URL: https://issues.jboss.org/browse/WFLY-4408
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Brian Stansberry
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Beta1
>
>
> The WFLY-2160 patch (https://github.com/wildfly/wildfly/pull/6976/files) made the "enabled" attribute support expressions but did not add transformers to reject that setting if a legacy host controller is using the profile.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4831) Clean up HornetQ modules
In-Reply-To: <JIRA.12576286.1435240409000@Atlassian.JIRA>
References: <JIRA.12576286.1435240409000@Atlassian.JIRA>
	<JIRA.12576286.1435240409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576286.1435240409000.88983.1512577289794@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4831.
----------------------------


> Clean up HornetQ modules
> ------------------------
>
>                 Key: WFLY-4831
>                 URL: https://issues.jboss.org/browse/WFLY-4831
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> With the messaging subsystem becoming legacy and its runtime being removed, there is no sense to keep modules for HornetQ server runtime.
> However, we still need modules for:
> * HornetQ client (required for forward protocol compatibility)
> * HornetQ journal (used by other modules such as the transaction subsystem to provide its logging store)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5315) Remove the Infinispan
 Directory integration, moves as an extension provided by Infinispan
In-Reply-To: <JIRA.12584454.1441816790000@Atlassian.JIRA>
References: <JIRA.12584454.1441816790000@Atlassian.JIRA>
	<JIRA.12584454.1441816790000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584454.1441816790000.88988.1512577289898@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5315.
----------------------------


> Remove the Infinispan Directory integration, moves as an extension provided by Infinispan
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5315
>                 URL: https://issues.jboss.org/browse/WFLY-5315
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering, JPA / Hibernate
>            Reporter: Sanne Grinovero
>            Assignee: Sanne Grinovero
>             Fix For: 10.0.0.CR1
>
>
> We decided to remove the Lucene / Infinispan Directory integration from the standard WildFly build, as it requires advanced Infinispan knowledge which is more suited for an Infinispan power user.
> Such advanced users should better use the latest version provided by the Infinispan project: Infinispan will provide "add-on" modules for the various WildFly releases.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4871) Upgrade to Hibernate Search
	5.3.0.Final
In-Reply-To: <JIRA.12577127.1436200859000@Atlassian.JIRA>
References: <JIRA.12577127.1436200859000@Atlassian.JIRA>
	<JIRA.12577127.1436200859000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577127.1436200859000.88994.1512577290046@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4871.
----------------------------


> Upgrade to Hibernate Search 5.3.0.Final
> ---------------------------------------
>
>                 Key: WFLY-4871
>                 URL: https://issues.jboss.org/browse/WFLY-4871
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JPA / Hibernate
>            Reporter: Sanne Grinovero
>            Assignee: Sanne Grinovero
>             Fix For: 10.0.0.Alpha5
>
>
> The main reason for this upgrade is that some changes are needed in modules structure between Hibernate Search 5.2 to 5.3.
> Wildfly is currently using HS 5.2 but will require >=5.4 to be compatible with Hibernate ORM 5.
> So applying this intermediate step towards HS 5.3 will make the Hibernate ORM 5 pull request easier.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5041) Test case for Reuse
 authenticated subject from incoming context when security domains match
In-Reply-To: <JIRA.12580027.1438343996000@Atlassian.JIRA>
References: <JIRA.12580027.1438343996000@Atlassian.JIRA>
	<JIRA.12580027.1438343996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580027.1438343996000.88997.1512577290139@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5041.
----------------------------


> Test case for Reuse authenticated subject from incoming context when security domains match
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5041
>                 URL: https://issues.jboss.org/browse/WFLY-5041
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Lukas
>             Fix For: 10.0.0.Beta1
>
>
> Add tests for Reuse authenticated subject from incoming context when security domains match.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4925) Admin in Monitor role can
 execute test-connection-in-pool op
In-Reply-To: <JIRA.12578080.1436922755000@Atlassian.JIRA>
References: <JIRA.12578080.1436922755000@Atlassian.JIRA>
	<JIRA.12578080.1436922755000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578080.1436922755000.89001.1512577290210@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4925.
----------------------------


> Admin in Monitor role can execute test-connection-in-pool op
> ------------------------------------------------------------
>
>                 Key: WFLY-4925
>                 URL: https://issues.jboss.org/browse/WFLY-4925
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Brian Stansberry
>            Assignee: Jesper Pedersen
>             Fix For: 10.0.0.Alpha6
>
>
> This should not work, as the Monitor role is not allowed to do anything that modifies any state:
> {code}
> [standalone at localhost:9990 data-source=ExampleDS] :test-connection-in-pool{roles=Monitor}
> {
>     "outcome" => "success",
>     "result" => [true]
> }
> {code}
> I believe the problem is PoolOperations L75:
> {code}
> final ServiceController<?> managementRepoService = context.getServiceRegistry(false).getService(
>         ConnectorServices.MANAGEMENT_REPOSITORY_SERVICE);
> {code}
> The parameter to context.getServiceRegistry(...) must be 'true' if the operation is going to use the returned service registry to perform any form of state modification. So I believe all the PoolOperation subclasses should provide a param to PoolOperation's constructor that can be used to set this value. I believe in all subclasses except DumpQueuedThreadInPool this param should be 'true'.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4564) Switch to version 4 of the
 management schema
In-Reply-To: <JIRA.12569906.1430158269000@Atlassian.JIRA>
References: <JIRA.12569906.1430158269000@Atlassian.JIRA>
	<JIRA.12569906.1430158269000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569906.1430158269000.89004.1512577290303@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4564.
----------------------------


> Switch to version 4 of the management schema
> --------------------------------------------
>
>                 Key: WFLY-4564
>                 URL: https://issues.jboss.org/browse/WFLY-4564
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4532) Clean up jboss-as-web_2_*.xsd
	schemas
In-Reply-To: <JIRA.12568743.1429291405000@Atlassian.JIRA>
References: <JIRA.12568743.1429291405000@Atlassian.JIRA>
	<JIRA.12568743.1429291405000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568743.1429291405000.89008.1512577290372@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4532.
----------------------------


> Clean up jboss-as-web_2_*.xsd schemas
> -------------------------------------
>
>                 Key: WFLY-4532
>                 URL: https://issues.jboss.org/browse/WFLY-4532
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> The last jboss-as-web schema included in a community release is jboss-as-web_2_0.xsd
> JBoss EAP contains both jboss-as-web_2_1.xsd and jboss-as-web_2_2.xsd
> I believe something was mistakenly added to the 2.1 schema in EAP, this was forward ported to WildFly - then the change to 2.1 was reverted in EAP and a 2.2 schema added.
> Version 2.1 and 2.2 of the schemas need porting from EAP to WildFly and the parsers updated to support them accordingly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5055) JobControlTestCase fails
	intermittently
In-Reply-To: <JIRA.12580310.1438722732000@Atlassian.JIRA>
References: <JIRA.12580310.1438722732000@Atlassian.JIRA>
	<JIRA.12580310.1438722732000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580310.1438722732000.89011.1512577290505@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5055.
----------------------------


> JobControlTestCase fails intermittently 
> ----------------------------------------
>
>                 Key: WFLY-5055
>                 URL: https://issues.jboss.org/browse/WFLY-5055
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch, Test Suite
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 10.0.0.Beta1
>
>
> See http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=63411&buildTypeId=WFPR



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4780) Provide a migration
 management operation for JBossWeb to Undertow
In-Reply-To: <JIRA.12574898.1434219962000@Atlassian.JIRA>
References: <JIRA.12574898.1434219962000@Atlassian.JIRA>
	<JIRA.12574898.1434219962000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574898.1434219962000.89016.1512577290596@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4780.
----------------------------


> Provide a migration management operation for JBossWeb to Undertow 
> ------------------------------------------------------------------
>
>                 Key: WFLY-4780
>                 URL: https://issues.jboss.org/browse/WFLY-4780
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Jason Greene
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Beta1
>
>
> Provide a management operation that performs a one-time conversion from the JBossWeb subsystem into the Undertow subsystem. This allows users using the CLI to perform a migration, as well as tools such as WindUp to also execute the change.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5320) Jacorb :migrate operation
 does not return migration-warnings
In-Reply-To: <JIRA.12584582.1441895443000@Atlassian.JIRA>
References: <JIRA.12584582.1441895443000@Atlassian.JIRA>
	<JIRA.12584582.1441895443000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584582.1441895443000.89021.1512577290706@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5320.
----------------------------


> Jacorb :migrate operation does not return migration-warnings
> ------------------------------------------------------------
>
>                 Key: WFLY-5320
>                 URL: https://issues.jboss.org/browse/WFLY-5320
>             Project: WildFly
>          Issue Type: Task
>          Components: IIOP
>    Affects Versions: 10.0.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.CR1
>
>         Attachments: standalone-full.tomig.inital.xml
>
>
> If I run migrate operation on jacorb subsystem the result of the operation is
> {code}
> /subsystem=jacorg:migrate()
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> {code}
> But the result should be
> {code}
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> }
> {code}
> Try the same with messaging or web subsystem
> {code}
> /subsystem=web:migrate()
> {
>     "outcome" => "success",
>     "result" => {"migration-warnings" => []}
> {code}
> To reproduce
>  - compile latest wildfly from github
>  - use the attached file standalone-full.tomig.inital.xml
>  - {{./bin/standalone.sh -c standalone-full.tomig.initial.xml --admin-only}}
>  - ./bin/jboss-cli.sh -c --controller=remote://localhost:9999
>  - /subsystem=jacorb:migrate()



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4887) Upgrade Narayana to
	5.2.0.Final
In-Reply-To: <JIRA.12577354.1436343528000@Atlassian.JIRA>
References: <JIRA.12577354.1436343528000@Atlassian.JIRA>
	<JIRA.12577354.1436343528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577354.1436343528000.89026.1512577290840@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4887.
----------------------------


> Upgrade Narayana to 5.2.0.Final
> -------------------------------
>
>                 Key: WFLY-4887
>                 URL: https://issues.jboss.org/browse/WFLY-4887
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 10.0.0.Alpha5
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5039) Batch JobXmlResolverService
 should safe copy values from the maps
In-Reply-To: <JIRA.12579921.1438274999000@Atlassian.JIRA>
References: <JIRA.12579921.1438274999000@Atlassian.JIRA>
	<JIRA.12579921.1438274999000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579921.1438274999000.89029.1512577290901@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5039.
----------------------------


> Batch JobXmlResolverService should safe copy values from the maps
> -----------------------------------------------------------------
>
>                 Key: WFLY-5039
>                 URL: https://issues.jboss.org/browse/WFLY-5039
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 10.0.0.Beta1
>
>
> {code}
> 2015-07-30 12:37:31,658 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.subunit."jslxml_ejb_vehicle.ear"."jslxml_ejb_vehicle_client.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."jslxml_ejb_vehicle.ear"."jslxml_ejb_vehicle_client.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "jslxml_ejb_vehicle_client.jar" of deployment "jslxml_ejb_vehicle.ear"
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.Alpha11.jar:2.0.0.Alpha11]
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
>   at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
> Caused by: java.util.ConcurrentModificationException
>   at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) [rt.jar:1.8.0_40]
>   at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) [rt.jar:1.8.0_40]
>   at org.wildfly.extension.batch.jberet.deployment.BatchDeploymentResourceProcessor.deploy(BatchDeploymentResourceProcessor.java:60)
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.Alpha11.jar:2.0.0.Alpha11]
>   ... 5 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4901) Fix or @Ignore
 org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptTestCase.encryptedAndSignedRequest
In-Reply-To: <JIRA.12577641.1436509655000@Atlassian.JIRA>
References: <JIRA.12577641.1436509655000@Atlassian.JIRA>
	<JIRA.12577641.1436509655000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577641.1436509655000.89034.1512577291034@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4901.
----------------------------


> Fix or @Ignore org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptTestCase.encryptedAndSignedRequest
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4901
>                 URL: https://issues.jboss.org/browse/WFLY-4901
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Rostislav Svoboda
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Beta2
>
>
> Brian Stansberry @here who is going to fix or @Ignore org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptTestCase.encryptedAndSignedRequest ?
> Stuart Douglas I am pretty sure it is a web services issue
> Stuart Douglas these failures started happening after a WS upgrade a while back
> David M. Lloyd @RostislavSvoboda added it



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4863) Journal file size
 configuration attribute changed
In-Reply-To: <JIRA.12576918.1435850226000@Atlassian.JIRA>
References: <JIRA.12576918.1435850226000@Atlassian.JIRA>
	<JIRA.12576918.1435850226000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576918.1435850226000.89039.1512577291144@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4863.
----------------------------


> Journal file size configuration attribute changed
> -------------------------------------------------
>
>                 Key: WFLY-4863
>                 URL: https://issues.jboss.org/browse/WFLY-4863
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> Attribute journal file-size is set to 102400 bytes in messaging subsystem (in Wildfly 9 with ActiveMQ). This attribute was not set in EAP 6.x and its default value was 10Mb. Current value 102400 bytes causes warnings if message of specific size is sent to server as it is the same value of the connection-factory's min-large-message-size



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4653) Weld thread pool should be
	wildfly global
In-Reply-To: <JIRA.12572257.1432133866000@Atlassian.JIRA>
References: <JIRA.12572257.1432133866000@Atlassian.JIRA>
	<JIRA.12572257.1432133866000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572257.1432133866000.89044.1512577291239@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4653.
----------------------------


> Weld thread pool should be wildfly global
> -----------------------------------------
>
>                 Key: WFLY-4653
>                 URL: https://issues.jboss.org/browse/WFLY-4653
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CDI / Weld
>    Affects Versions: 9.0.0.CR1
>            Reporter: Sebastian Maurer
>            Assignee: Jozef Hartinger
>             Fix For: 10.0.0.Alpha3
>
>
> Weld keeps a thread pool for each deployment.
> Per default the pool is filled with "numProcessors" threads (see http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html)
> When having many deployments, a single thread pool for the wildfly instance could improve the overall performance.
> This thread pool should be configurable in the weld subsystem of the wildfly configuration (e.g. standalone.xml).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5064) Upgrade HAL to 2.8.5
In-Reply-To: <JIRA.12580457.1438849160000@Atlassian.JIRA>
References: <JIRA.12580457.1438849160000@Atlassian.JIRA>
	<JIRA.12580457.1438849160000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580457.1438849160000.89052.1512577291382@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5064.
----------------------------


> Upgrade HAL to 2.8.5
> --------------------
>
>                 Key: WFLY-5064
>                 URL: https://issues.jboss.org/browse/WFLY-5064
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5161) Can't set attributes of
 element transport-config in CLI
In-Reply-To: <JIRA.12582125.1440154669000@Atlassian.JIRA>
References: <JIRA.12582125.1440154669000@Atlassian.JIRA>
	<JIRA.12582125.1440154669000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582125.1440154669000.89049.1512577291328@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5161.
----------------------------


> Can't set attributes of element transport-config in CLI
> -------------------------------------------------------
>
>                 Key: WFLY-5161
>                 URL: https://issues.jboss.org/browse/WFLY-5161
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.CR1
>
>
> It's not possible to set attributes of element {{transport-config}} in CLI.
> When I run {{:read-resource()}} I get
> {code}
> /subsystem=iiop-openjdk:read-resource()
> {
>     "outcome" => "success",
>     "result" => {
>         "add-component-via-interceptor" => true,
>         "auth-method" => "username_password",
>         "caller-propagation" => "none",
>         "client-requires" => "None",
>         "client-supports" => "ServerAuth",
>         "confidentiality" => "none",
>         "detect-misordering" => "none",
>         "detect-replay" => "none",
>         "export-corbaloc" => true,
>         "giop-version" => "1.2",
>         "high-water-mark" => undefined,
>         "integrity" => "required",
>         "number-to-reclaim" => undefined,
>         "persistent-server-id" => "1",
>         "properties" => undefined,
>         "realm" => undefined,
>         "required" => false,
>         "root-context" => "JBoss/Naming/root",
>         "security" => "identity",
>         "security-domain" => undefined,
>         "server-requires" => "None",
>         "server-supports" => "MutualAuth",
>         "socket-binding" => "iiop",
>         "ssl-socket-binding" => "iiop-ssl",
>         "support-ssl" => false,
>         "transactions" => "spec",
>         "trust-in-client" => "none",
>         "trust-in-target" => "none"
>     }
> }
> {code}
> but XML can contain two emelents
> {code}
> <client-transport integrity="supported" confidentiality="supported" trust-in-target="supported" trust-in-client="supported" detect-replay="supported" detect-misordering="supported" />
> <transport-config integrity="supported" confidentiality="supported" trust-in-target="supported" trust-in-client="supported" detect-replay="supported" detect-misordering="supported" />
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4969) Update JSF based on Mojarra
	2.2.12
In-Reply-To: <JIRA.12578658.1437424284000@Atlassian.JIRA>
References: <JIRA.12578658.1437424284000@Atlassian.JIRA>
	<JIRA.12578658.1437424284000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578658.1437424284000.89059.1512577291506@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4969.
----------------------------


> Update JSF based on Mojarra 2.2.12
> ----------------------------------
>
>                 Key: WFLY-4969
>                 URL: https://issues.jboss.org/browse/WFLY-4969
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JSF
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: 9.0.2.Final, 10.0.0.Beta1
>
>
> Update JSF since Mojarra 2.2.12 was just released.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5215) [Migration operation] [Web to
 Undertow] Scheme attribute of ajp connector is not migrated
In-Reply-To: <JIRA.12582699.1440600642000@Atlassian.JIRA>
References: <JIRA.12582699.1440600642000@Atlassian.JIRA>
	<JIRA.12582699.1440600642000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582699.1440600642000.89063.1512577291571@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5215.
----------------------------


> [Migration operation] [Web to Undertow] Scheme attribute of ajp connector is not migrated
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5215
>                 URL: https://issues.jboss.org/browse/WFLY-5215
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>
> Scheme attribute of AJP connector is not migrated.
> Web AJP configuration
> {noformat}
> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
> {noformat}
> should be migrated to
> {noformat}
> <ajp-listener name="ajp" socket-binding="ajp" scheme="http"/>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4854) Exclude
 org.jboss.logmanager:jboss-logmanager from wildfly-client-all
 (jboss-client.jar)
In-Reply-To: <JIRA.12576784.1435763108000@Atlassian.JIRA>
References: <JIRA.12576784.1435763108000@Atlassian.JIRA>
	<JIRA.12576784.1435763108000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576784.1435763108000.89067.1512577291641@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4854.
----------------------------


> Exclude org.jboss.logmanager:jboss-logmanager from wildfly-client-all (jboss-client.jar)
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-4854
>                 URL: https://issues.jboss.org/browse/WFLY-4854
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>            Reporter: Martin Simka
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> Exclude org.jboss.logmanager:jboss-logmanager from wildfly-client-all (jboss-client.jar)
> its presence causes TCK failures with error:
> {noformat}
> IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> {noformat}
> as LogManager is loaded twice, from jboss-client.jar and from module. It was brought in together with ActiveMQ Artemis messaging. 
> {noformat}
> [INFO] --- maven-dependency-plugin:2.9:tree (default-cli) @ wildfly-client-all ---
> [INFO] org.wildfly:wildfly-client-all:jar:10.0.0.Alpha5-SNAPSHOT
> [INFO] +- org.wildfly:wildfly-ejb-client-bom:pom:10.0.0.Alpha5-SNAPSHOT:compile
> [INFO] |  +- org.jboss:jboss-ejb-client:jar:2.1.1.Final:compile
> [INFO] |  +- org.jboss:jboss-remote-naming:jar:2.0.4.Final:compile
> [INFO] |  +- org.jboss.logging:jboss-logging:jar:3.2.1.Final:compile
> [INFO] |  +- org.jboss.marshalling:jboss-marshalling:jar:1.4.10.Final:compile
> [INFO] |  +- org.jboss.marshalling:jboss-marshalling-river:jar:1.4.10.Final:compile
> [INFO] |  +- org.jboss.remoting:jboss-remoting:jar:4.0.9.Final:compile
> [INFO] |  +- org.jboss.sasl:jboss-sasl:jar:1.0.5.Final:compile
> [INFO] |  +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:compile
> [INFO] |  +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:compile
> [INFO] |  +- org.jboss.xnio:xnio-api:jar:3.3.1.Final:compile
> [INFO] |  \- org.jboss.xnio:xnio-nio:jar:3.3.1.Final:compile
> [INFO] +- org.wildfly:wildfly-jms-client-bom:pom:10.0.0.Alpha5-SNAPSHOT:compile
> [INFO] |  +- org.apache.activemq:artemis-commons:jar:1.0.0:compile
> [INFO] |  |  +- org.jboss.logmanager:jboss-logmanager:jar:2.0.0.Final:compile
> [INFO] |  |  \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
> [INFO] |  |     \- commons-collections:commons-collections:jar:3.2.1:compile
> [INFO] |  +- org.apache.activemq:artemis-core-client:jar:1.0.0:compile
> [INFO] |  |  +- org.jgroups:jgroups:jar:3.6.4.Final:compile
> [INFO] |  |  +- org.apache.activemq:artemis-selector:jar:1.0.0:compile
> [INFO] |  |  \- org.apache.activemq:artemis-journal:jar:1.0.0:compile
> [INFO] |  |     \- org.apache.activemq:artemis-native:jar:1.0.0:compile
> [INFO] |  +- org.apache.activemq:artemis-jms-client:jar:1.0.0:compile
> [INFO] |  |  +- org.apache.geronimo.specs:geronimo-jms_2.0_spec:jar:1.0-alpha-1:compile
> [INFO] |  |  \- javax.inject:javax.inject:jar:1:compile
> [INFO] |  +- org.hornetq:hornetq-commons:jar:2.4.7.Final:compile
> [INFO] |  +- org.hornetq:hornetq-core-client:jar:2.4.7.Final:compile
> [INFO] |  |  \- org.hornetq:hornetq-journal:jar:2.4.7.Final:compile
> [INFO] |  |     \- org.hornetq:hornetq-native:jar:2.4.7.Final:compile
> [INFO] |  +- org.hornetq:hornetq-jms-client:jar:2.4.7.Final:compile
> [INFO] |  +- io.netty:netty-all:jar:4.0.26.Final:compile
> [INFO] |  +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:compile
> [INFO] |  \- org.slf4j:jcl-over-slf4j:jar:1.7.7.jbossorg-1:compile
> [INFO] |     \- org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1:compile
> [INFO] +- org.jboss.remotingjmx:remoting-jmx:jar:2.0.1.Final:compile
> [INFO] \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.3.Final:compile
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5099) Transaction subsystem startup
 failed with setting the "use-hornetq-store"
In-Reply-To: <JIRA.12581126.1439473788000@Atlassian.JIRA>
References: <JIRA.12581126.1439473788000@Atlassian.JIRA>
	<JIRA.12581126.1439473788000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581126.1439473788000.89072.1512577291810@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5099.
----------------------------


> Transaction subsystem startup failed with setting the "use-hornetq-store"
> -------------------------------------------------------------------------
>
>                 Key: WFLY-5099
>                 URL: https://issues.jboss.org/browse/WFLY-5099
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 10.0.0.Beta2
>
>
> using  <use-hornetq-store  enable-async-io="true"/> in standalone.xml and wildfly starts failed with
> {code}
> 21:45:42,140 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaRecoveryManager" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service
>     Caused by: com.arjuna.ats.arjuna.exceptions.FatalError: ARJUNA012135: Could not create Store type: com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor
>     Caused by: java.lang.NoClassDefFoundError: org/apache/activemq/artemis/core/journal/SequentialFileFactory
>     Caused by: java.lang.ClassNotFoundException: org.apache.activemq.artemis.core.journal.SequentialFileFactory from [Module \"org.jboss.jts:main\" from local module loader @2aae9190 (finder: local module finder @2f333739 (roots: /home/zhfeng/work/zhfeng/jboss-as/build/target/wildfly-10.0.0.Beta2-SNAPSHOT/modules,/home/zhfeng/work/zhfeng/jboss-as/build/target/wildfly-10.0.0.Beta2-SNAPSHOT/modules/system/layers/base))]"}}
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:31 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5052) NoClassDefFoundError at
 JAX-WS webservice deployment
In-Reply-To: <JIRA.12580274.1438700157000@Atlassian.JIRA>
References: <JIRA.12580274.1438700157000@Atlassian.JIRA>
	<JIRA.12580274.1438700157000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580274.1438700157000.89078.1512577291929@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5052.
----------------------------


> NoClassDefFoundError at JAX-WS webservice deployment
> ----------------------------------------------------
>
>                 Key: WFLY-5052
>                 URL: https://issues.jboss.org/browse/WFLY-5052
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 9.0.1.Final
>            Reporter: Gregory Lardiere
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Beta1
>
>         Attachments: SampleWS.war, SampleWS.zip
>
>
> The exception *java.lang.NoClassDefFoundError: org/apache/ws/commons/schema/XmlSchemaAllMember* is thrown when deploying a JAX-WS webservice : 
> {code}
> 2015-08-04 16:32:18,222 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."SampleWS.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."SampleWS.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "SampleWS.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> 	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.lang.NoClassDefFoundError: org/apache/ws/commons/schema/XmlSchemaAllMember
> 	at org.apache.cxf.common.xmlschema.SchemaCollection.addCrossImports(SchemaCollection.java:315)
> 	at org.apache.cxf.common.xmlschema.SchemaCollection.addCrossImportsType(SchemaCollection.java:307)
> 	at org.apache.cxf.common.xmlschema.SchemaCollection.addOneSchemaCrossImports(SchemaCollection.java:252)
> 	at org.apache.cxf.common.xmlschema.SchemaCollection.addCrossImports(SchemaCollection.java:236)
> 	at org.apache.cxf.jaxb.JAXBSchemaInitializer.buildExceptionType(JAXBSchemaInitializer.java:605)
> 	at org.apache.cxf.jaxb.JAXBSchemaInitializer.checkForExistence(JAXBSchemaInitializer.java:326)
> 	at org.apache.cxf.jaxb.JAXBSchemaInitializer.begin(JAXBSchemaInitializer.java:150)
> 	at org.apache.cxf.service.ServiceModelVisitor.visitOperation(ServiceModelVisitor.java:120)
> 	at org.apache.cxf.service.ServiceModelVisitor.walk(ServiceModelVisitor.java:74)
> 	at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:403)
> 	at org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)
> 	at org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:467)
> 	at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:712)
> 	at org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527)
> 	at org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:261)
> 	at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:215)
> 	at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)
> 	at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159)
> 	at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> 	at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:456)
> 	at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:334)
> 	at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:79)
> 	at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251)
> 	at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539)
> 	at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:119)
> 	at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:120)
> 	at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:66)
> 	at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> Caused by: java.lang.ClassNotFoundException: org.apache.ws.commons.schema.XmlSchemaAllMember from [Module "org.apache.cxf:main" from local module loader @14899482 (finder: local module finder @21588809 (roots: /tmp/wildfly-9.0.1.Final/modules,/tmp/wildfly-9.0.1.Final/modules/system/layers/base))]
> 	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)
> 	... 34 more
> {code}
> Replacing xmlschema-core-2.0.2.jar with xmlschema-core-2.2.1.jar fixes this problem.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:32 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 6 Dec 2017 11:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.89082.1512577292009@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498050#comment-13498050 ] 

Darran Lofthouse commented on ELY-1455:
---------------------------------------

I can probably reverse engineer it from your config but do you have your full table structure?  Just in case that is affecting queries executing again.

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 11:21:32 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4540) NPE if dependency missing
In-Reply-To: <JIRA.12568850.1429536456000@Atlassian.JIRA>
References: <JIRA.12568850.1429536456000@Atlassian.JIRA>
	<JIRA.12568850.1429536456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568850.1429536456000.89085.1512577292067@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4540.
----------------------------


> NPE if dependency missing
> -------------------------
>
>                 Key: WFLY-4540
>                 URL: https://issues.jboss.org/browse/WFLY-4540
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 9.0.0.Beta2
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 10.0.0.Alpha4
>
>
> When creating a feature pack, a missing dependency caused the AetherArtifactFile resolver to throw an NPE.  However, it did not give any clue as to which dependency was missing.  I will submit a patch for this so that a proper error message can accompany a RuntimeException.
> Here is the stack trace for the NPE:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1.0.0.Alpha8:build (feature-pack-
> build) on project keycloak-feature-pack-adapter: Execution feature-pack-build of goal org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1.0.0.Alpha8:build failed:
>  java.lang.RuntimeException: java.lang.NullPointerException
>         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
>         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>         at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>         at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>         at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>         at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
>         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
>         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
>         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
>         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
>         at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
>         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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>         at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>         at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>         at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution feature-pack-build of goal org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1.0.0.Alpha8:b
> uild failed: java.lang.RuntimeException: java.lang.NullPointerException
>         at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
>         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>         ... 19 more
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException
>         at org.wildfly.build.plugin.FeaturePackBuildMojo.execute(FeaturePackBuildMojo.java:119)
>         at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
>         ... 20 more
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
>         at org.wildfly.build.featurepack.FeaturePackBuilder.build(FeaturePackBuilder.java:87)
>         at org.wildfly.build.plugin.FeaturePackBuildMojo.execute(FeaturePackBuildMojo.java:117)
>         ... 21 more
> Caused by: java.lang.NullPointerException
>         at org.wildfly.build.AetherArtifactFileResolver.getArtifactFile(AetherArtifactFileResolver.java:66)
>         at org.wildfly.build.pack.model.FeaturePackFactory.createPack(FeaturePackFactory.java:66)
>         at org.wildfly.build.pack.model.FeaturePackFactory.createPack(FeaturePackFactory.java:50)
>         at org.wildfly.build.featurepack.FeaturePackBuilder.processDependencies(FeaturePackBuilder.java:108)
>         at org.wildfly.build.featurepack.FeaturePackBuilder.build(FeaturePackBuilder.java:81)
>         ... 22 more
> [ERROR]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:32 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3838) Wildcard (*) for ejb-name
 should work for all applicable occurences of the ejb-name element
In-Reply-To: <JIRA.12551664.1410345294000@Atlassian.JIRA>
References: <JIRA.12551664.1410345294000@Atlassian.JIRA>
	<JIRA.12551664.1410345294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551664.1410345294000.89091.1512577292222@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-3838.
----------------------------


> Wildcard (*) for ejb-name should work for all applicable occurences of the ejb-name element
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3838
>                 URL: https://issues.jboss.org/browse/WFLY-3838
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>    Affects Versions: 8.1.0.Final
>            Reporter: Jan Martiska
>             Fix For: 10.0.0.Beta1
>
>
> As implemented via WFLY-3497, ejb-name element of jboss-ejb3.xml now accepts a wildcard (*) to denote all EJBs in a deployment. This should work for applicable occurences, but it only seems to work when specifying transaction timeouts.
> This currently doesn't work:
> - assembly-descriptor/exclude-list/method/ejb-name=* (to declare method exclusions)
> - assembly-descriptor/method-permission/method/ejb-name=* (to declare method permissions)
> I prepared a testcase which demonstrates this (and is currently failing): https://github.com/jmartisk/wildfly/commit/eaad1da5e9a6553f4365d650f408214f99522df6



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:32 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4430) Remove transport from DWM
In-Reply-To: <JIRA.12565928.1426471190000@Atlassian.JIRA>
References: <JIRA.12565928.1426471190000@Atlassian.JIRA>
	<JIRA.12565928.1426471190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565928.1426471190000.89094.1512577292275@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4430.
----------------------------


> Remove transport from DWM
> -------------------------
>
>                 Key: WFLY-4430
>                 URL: https://issues.jboss.org/browse/WFLY-4430
>             Project: WildFly
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Blocker
>             Fix For: 10.0.0.Beta1
>
>
> Remove 'transport' and 'transportType' from DWM. Use the unique name of the DWM for channel name



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:32 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5195) Persistent timers sometimes
 remain IN_TIMEOUT in database and don't ever activate again
In-Reply-To: <JIRA.12582418.1440492023000@Atlassian.JIRA>
References: <JIRA.12582418.1440492023000@Atlassian.JIRA>
	<JIRA.12582418.1440492023000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582418.1440492023000.89099.1512577292408@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5195.
----------------------------


> Persistent timers sometimes remain IN_TIMEOUT in database and don't ever activate again
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-5195
>                 URL: https://issues.jboss.org/browse/WFLY-5195
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Jan Martiska
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>         Attachments: in-timeout-reproducer.zip
>
>
> The scenario:
> A persistent timer goes off right before its application gets undeployed
> {noformat}
> &amp#27;[0m&amp#27;[32m08:43:38,086 DEBUG [org.jboss.as.ejb3] (EJB default - 1) Timer task invoked at: Tue Aug 25 08:43:38 CEST 2015 for timer [id=d563c5b3-c98c-44c9-87f6-04a492280a67 timedObjectId=testTimerServiceSerialization.a.TimerServiceSerializationBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl at 43ca0624 initialExpiration=Tue Aug 25 08:43:35 CEST 2015 intervalDuration(in milli sec)=100 nextExpiration=Tue Aug 25 08:43:38 CEST 2015 timerState=ACTIVE info=org.jboss.as.test.integration.ejb.timerservice.serialization.InfoA at 1ce85ecb]
> {noformat}
> The timer changes its state to IN_TIMEOUT and persists this into the database.
> It fails to invoke the bean method, because the application is no longer available
> {noformat}
> &amp#27;[0m&amp#27;[31m08:43:38,515 ERROR [org.jboss.as.ejb3] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=d563c5b3-c98c-44c9-87f6-04a492280a67 timedObjectId=testTimerServiceSerialization.a.TimerServiceSerializationBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl at 43ca0624 initialExpiration=Tue Aug 25 08:43:35 CEST 2015 intervalDuration(in milli sec)=100 nextExpiration=Tue Aug 25 08:43:38 CEST 2015 timerState=IN_TIMEOUT info=org.jboss.as.test.integration.ejb.timerservice.serialization.InfoA at 1ce85ecb]: java.lang.IllegalStateException
>         at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
>         at org.jboss.as.ejb3.timerservice.TimerServiceImpl.getInvoker(TimerServiceImpl.java:564)
>         at org.jboss.as.ejb3.timerservice.TimerTask.invokeBeanMethod(TimerTask.java:188)
>         at org.jboss.as.ejb3.timerservice.TimerTask.callTimeout(TimerTask.java:184)
>         at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
>         at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1224)
>         at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
>         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)
> {noformat}
> It considers retrying, but then it doesn't retry, because the state is IN_TIMEOUT
> {noformat}
> 08:43:38,515 INFO  [org.jboss.as.ejb3] (EJB default - 1) WFLYEJB0021: Timer: [id=d563c5b3-c98c-44c9-87f6-04a492280a67 timedObjectId=testTimerServiceSerialization.a.TimerServiceSerializationBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl at 43ca0624 initialExpiration=Tue Aug 25 08:43:35 CEST 2015 intervalDuration(in milli sec)=100 nextExpiration=Tue Aug 25 08:43:38 CEST 2015 timerState=IN_TIMEOUT info=org.jboss.as.test.integration.ejb.timerservice.serialization.InfoA at 1ce85ecb] will be retried                                                                                                                                               
> 08:43:38,515 INFO  [org.jboss.as.ejb3] (EJB default - 1) WFLYEJB0024: Timer is not active, skipping retry of timer: [id=d563c5b3-c98c-44c9-87f6-04a492280a67 timedObjectId=testTimerServiceSerialization.a.TimerServiceSerializationBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl at 43ca0624 initialExpiration=Tue Aug 25 08:43:35 CEST 2015 intervalDuration(in milli sec)=100 nextExpiration=Tue Aug 25 08:43:38 CEST 2015 timerState=IN_TIMEOUT info=org.jboss.as.test.integration.ejb.timerservice.serialization.InfoA at 1ce85ecb]
> {noformat}
> It gives up and tries to persist the state back to ACTIVE, but it fails, because the DatabaseTimerPersistence service is no longer available
> {noformat}
> 08:43:38,516 WARN  [org.jboss.as.ejb3] (EJB default - 1) WFLYEJB0016: Timer persistence is not enabled, persistent timers will not survive JVM restarts
> {noformat}
> So the state remains IN_TIMEOUT in the database. When the application is redeployed, it is initialized with this state and it never goes off again.
> This happens with a JDBC storage in a database that is slow enough so that the update of state to IN_TIMEOUT proceeds correctly, but the actual bean method invocation fails already.
> Attaching a reproducer which simulates a slow database using Byteman, so it can be run even with the ExampleDS.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:32 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5033) Upgrade Infinispan to 8.0
In-Reply-To: <JIRA.12579820.1438221573000@Atlassian.JIRA>
References: <JIRA.12579820.1438221573000@Atlassian.JIRA>
	<JIRA.12579820.1438221573000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579820.1438221573000.89105.1512577292548@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5033.
----------------------------


> Upgrade Infinispan to 8.0
> -------------------------
>
>                 Key: WFLY-5033
>                 URL: https://issues.jboss.org/browse/WFLY-5033
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3355) MDB fails to deploy on reload
In-Reply-To: <JIRA.12540773.1400077061000@Atlassian.JIRA>
References: <JIRA.12540773.1400077061000@Atlassian.JIRA>
	<JIRA.12540773.1400077061000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540773.1400077061000.89123.1512577293160@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-3355.
----------------------------


> MDB fails to deploy on reload
> -----------------------------
>
>                 Key: WFLY-3355
>                 URL: https://issues.jboss.org/browse/WFLY-3355
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, JMS
>    Affects Versions: 10.0.0.Alpha4
>         Environment: Windows 7, 64bit
>            Reporter: Bart Van Dosselaer
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Beta1
>
>         Attachments: leak-0.0.1-SNAPSHOT.jar
>
>
> When an MDB is deployed and a :reload command is issues, the application server fails to deploy this MDB.
> Stacktrace:
> {noformat}
> 2014-05-14 16:11:22,284 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 57) MSC000001: Failed to start service jboss.deployment.unit."wildfly-helloworld-mdb.war".component.HelloWorldQueueMDB.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-helloworld-mdb.war".component.HelloWorldQueueMDB.START: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57) [wildfly-ee-8.1.0.CR2.jar:8.1.0.CR2]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_55]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_55]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:215)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:186)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [wildfly-ee-8.1.0.CR2.jar:8.1.0.CR2]
> 	... 6 more
> Caused by: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.doFirstChecks(WorkManagerImpl.java:776) [ironjacamar-core-impl-1.1.5.Final.jar:1.1.5.Final]
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:617) [ironjacamar-core-impl-1.1.5.Final.jar:1.1.5.Final]
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:602) [ironjacamar-core-impl-1.1.5.Final.jar:1.1.5.Final]
> 	at org.hornetq.ra.inflow.HornetQActivation.start(HornetQActivation.java:264) [hornetq-ra-2.4.1.Final.jar:]
> 	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:166) [hornetq-ra-2.4.1.Final.jar:]
> 	at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:191) [ironjacamar-core-impl-1.1.5.Final.jar:1.1.5.Final]
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:213)
> 	... 8 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5084) [Migration operation]
 group-address/group-port/local-bind-address in discovery-group are not
 migrated
In-Reply-To: <JIRA.12580956.1439376463000@Atlassian.JIRA>
References: <JIRA.12580956.1439376463000@Atlassian.JIRA>
	<JIRA.12580956.1439376463000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580956.1439376463000.89128.1512577293308@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5084.
----------------------------


> [Migration operation] group-address/group-port/local-bind-address in discovery-group are not migrated
> -----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5084
>                 URL: https://issues.jboss.org/browse/WFLY-5084
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> During migration of discovery group with local-bind-address, group-address and group-port, those parameters are not migrated properly:
> For example HornetQ configuration:
> {code}
> <discovery-group name="groupC">
>                 <local-bind-address>localhost</local-bind-address>
>                 <group-address>224.0.1.105</group-address>
>                 <group-port>45678</group-port>
>                 <refresh-timeout>${refresh.timeout:3500}</refresh-timeout>
>                 <initial-wait-timeout>${initial.wait.timeout:7500}</initial-wait-timeout>
>             </discovery-group>
> {code}
> is migrated to Artemis like:
> {code}
>                 <discovery-group name="groupC" initial-wait-timeout="${initial.wait.timeout:7500}" refresh-timeout="${refresh.timeout:3500}"/>
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4813) CCE in
	XMLXaDataSourceRuntimeHandler.java
In-Reply-To: <JIRA.12575758.1434742328000@Atlassian.JIRA>
References: <JIRA.12575758.1434742328000@Atlassian.JIRA>
	<JIRA.12575758.1434742328000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575758.1434742328000.89132.1512577293390@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4813.
----------------------------


> CCE in XMLXaDataSourceRuntimeHandler.java
> -----------------------------------------
>
>                 Key: WFLY-4813
>                 URL: https://issues.jboss.org/browse/WFLY-4813
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Frank Langelage
>            Assignee: Jesper Pedersen
>             Fix For: 10.0.0.Alpha6
>
>         Attachments: DefaultDS-ds.xml
>
>
> 19.06. 19:52:13,830 ERROR [org.jboss.as.controller.management-operation#executeStep] WFLYCTL0013: Operation ("read-attribute") failed - address: ([
>     ("deployment" => "DefaultDS-ds.xml"),
>     ("subsystem" => "datasources"),
>     ("xa-data-source" => "java:jboss/datasources/DefaultDS")
> ]): java.lang.ClassCastException: org.jboss.jca.common.metadata.ds.DsXaPoolImpl cannot be cast to org.jboss.jca.common.api.metadata.ds.DsPool
> 	at org.jboss.as.connector.subsystems.datasources.XMLXaDataSourceRuntimeHandler.handleDatasourceAttribute(XMLXaDataSourceRuntimeHandler.java:146)
> 	at org.jboss.as.connector.subsystems.datasources.XMLXaDataSourceRuntimeHandler.executeReadAttribute(XMLXaDataSourceRuntimeHandler.java:54)
> 	at org.jboss.as.connector.subsystems.datasources.XMLXaDataSourceRuntimeHandler.executeReadAttribute(XMLXaDataSourceRuntimeHandler.java:43)
> 	at org.jboss.as.connector.subsystems.datasources.AbstractXMLDataSourceRuntimeHandler.executeRuntimeStep(AbstractXMLDataSourceRuntimeHandler.java:62)
> 	at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:822)
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:620)
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:373)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:349)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1201)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> 	at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> 	at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> 	at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> 	at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> 	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.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> 	at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> 	at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> 	at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> 	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(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 Dec  6 11:21:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5306) Should the :migrate operation
 remove the legacy extension in standalone?
In-Reply-To: <JIRA.12584386.1441798148000@Atlassian.JIRA>
References: <JIRA.12584386.1441798148000@Atlassian.JIRA>
	<JIRA.12584386.1441798148000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584386.1441798148000.89139.1512577293538@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5306.
----------------------------


> Should the :migrate operation remove the legacy extension in standalone?
> ------------------------------------------------------------------------
>
>                 Key: WFLY-5306
>                 URL: https://issues.jboss.org/browse/WFLY-5306
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ladislav Thon
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>
> The {{:migrate}} management operation creates a new subsystem and removes the legacy subsystem. It also adds an extension for the new subsystem, but it doesn't remove the legacy extension.
> The legacy extension must of course stay in place in managed domain (the {{:migrate}} operation could be clever and check other profiles if they still have the subsystem, but I'd consider this behavior out of scope), but for standalone, I think the extension could and should be removed. Ideas?
> Brian noted \[1\] that there might be technical obstacles in removing the extension, in which case I of course agree with rejecting.
> \[1\] http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004287.html



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4305) Script rumbles on after error
In-Reply-To: <JIRA.12562285.1422958906000@Atlassian.JIRA>
References: <JIRA.12562285.1422958906000@Atlassian.JIRA>
	<JIRA.12562285.1422958906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562285.1422958906000.89144.1512577293633@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4305.
----------------------------


> Script rumbles on after error
> -----------------------------
>
>                 Key: WFLY-4305
>                 URL: https://issues.jboss.org/browse/WFLY-4305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>             Fix For: 10.0.0.CR1
>
>
> After a failure in the script it rumbles on.
> {noformat}
> (master) carlo at devel01:~/work/wildfly$ ./build.sh clean
> ./tools/download-maven.sh: 20: ./tools/download-maven.sh: curl: not found
> Archive:  maven.zip
>   End-of-central-directory signature not found.  Either this file is not
>   a zipfile, or it constitutes one disk of a multi-part archive.  In the
>   latter case the central directory and zipfile comment will be found on
>   the last disk(s) of this archive.
> unzip:  cannot find zipfile directory in one of maven.zip or
>         maven.zip.zip, and cannot find maven.zip.ZIP, period.
> mv: cannot stat ?apache-maven*?: No such file or directory
> build.sh: Could not locate Maven; check $MVN or $MAVEN_HOME.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 11:21:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4692) Configure the distributions
 in the dist modules instead of the feature packs
In-Reply-To: <JIRA.12573065.1432799057000@Atlassian.JIRA>
References: <JIRA.12573065.1432799057000@Atlassian.JIRA>
	<JIRA.12573065.1432799057000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573065.1432799057000.89147.1512577293691@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4692.
----------------------------


> Configure the distributions in the dist modules instead of the feature packs
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-4692
>                 URL: https://issues.jboss.org/browse/WFLY-4692
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Build System
>    Affects Versions: 9.0.0.CR1
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>             Fix For: 10.0.0.Alpha5
>
>
> The distribution identification is done through the product.conf file and a product module that defines various properties.
> Those files and informations are added to the feature pack instead of being defined and added when the distribution is built.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5177)
 VaultedInjectedJMSContextTestCase is unable create session factory with
 security manager
In-Reply-To: <JIRA.12582282.1440406758000@Atlassian.JIRA>
References: <JIRA.12582282.1440406758000@Atlassian.JIRA>
	<JIRA.12582282.1440406758000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582282.1440406758000.89152.1512577293860@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5177.
----------------------------


> VaultedInjectedJMSContextTestCase is unable create session factory with security manager
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5177
>                 URL: https://issues.jboss.org/browse/WFLY-5177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> *Description of problem:*
> VaultedInjectedJMSContextTestCase is unable create session factory with security manager. Test ends with {{javax.jms.JMSRuntimeException: Failed to create session factory}}
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2  -DfailIfNoTests=false  -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=VaultedInjectedJMSContextTestCase
> *Actual results:*
> {noformat}
> javax.ejb.EJBException: javax.jms.JMSRuntimeException: Failed to create session factory
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:921)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:726)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXAContext(ActiveMQConnectionFactory.java:278)
> 	at org.wildfly.extension.messaging.activemq.deployment.JMSContextProducer$JMSContextWrapper.create(JMSContextProducer.java:192)
> 	at org.wildfly.extension.messaging.activemq.deployment.JMSContextProducer$JMSContextWrapper.getDelegate(JMSContextProducer.java:217)
> 	at org.wildfly.extension.messaging.activemq.deployment.JMSContextProducer$JMSContextWrapper.createProducer(JMSContextProducer.java:270)
> 	at org.jboss.as.test.integration.messaging.jms.context.auxiliary.VaultedMessageProducer.sendToDestination(VaultedMessageProducer.java:47)
> 	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.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.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59)
> 	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 java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.as.test.integration.messaging.jms.context.auxiliary.VaultedMessageProducer$$$view228.sendToDestination(Unknown Source)
> 	at org.jboss.as.test.integration.messaging.jms.context.VaultedInjectedJMSContextTestCase.sendMessage(VaultedInjectedJMSContextTestCase.java:164)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 11:21:33 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4835) Remove ClassIndex and replace
 with ClassReflectionIndex
In-Reply-To: <JIRA.12576364.1435305064000@Atlassian.JIRA>
References: <JIRA.12576364.1435305064000@Atlassian.JIRA>
	<JIRA.12576364.1435305064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576364.1435305064000.89156.1512577293973@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4835.
----------------------------


> Remove ClassIndex and replace with ClassReflectionIndex
> -------------------------------------------------------
>
>                 Key: WFLY-4835
>                 URL: https://issues.jboss.org/browse/WFLY-4835
>             Project: WildFly
>          Issue Type: Task
>          Components: Server
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha5
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4844) When Wildfly EJB timer
 finishes, the transaction is not fully committed.
In-Reply-To: <JIRA.12576505.1435602106000@Atlassian.JIRA>
References: <JIRA.12576505.1435602106000@Atlassian.JIRA>
	<JIRA.12576505.1435602106000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576505.1435602106000.89161.1512577294075@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4844.
----------------------------


> When Wildfly EJB timer finishes, the transaction is not fully committed. 
> -------------------------------------------------------------------------
>
>                 Key: WFLY-4844
>                 URL: https://issues.jboss.org/browse/WFLY-4844
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.0.Final
>         Environment: Ubuntu and Mac
>            Reporter: xiaodong xie
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.Alpha6
>
>
> When a Singleton EJB timer finishes, if the next run has already started but waiting on the write lock of Singleton EJB, the next run won't see the changes committed by the current run. So I assume when the EJB timers finishes, the transaction is not fully committed, or it's the next run that starts too early.
> Here is a test case that should be able to reproduce the issue we are facing. 
> https://github.com/xiaodong-xie/wildfly-singleton-timer
> Here is my analysis of this issue: 
> The CMTTxInterceptor is applied before ContainerManagedConcurrencyInterceptor. 
> So when waiting for the write lock of EJBReadWriteLock, we've already started the transaction, which IMHO is earlier than necessary. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4360) Remove jboss-common-core.jar
In-Reply-To: <JIRA.12563535.1424276065000@Atlassian.JIRA>
References: <JIRA.12563535.1424276065000@Atlassian.JIRA>
	<JIRA.12563535.1424276065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12563535.1424276065000.89165.1512577294256@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4360.
----------------------------


> Remove jboss-common-core.jar
> ----------------------------
>
>                 Key: WFLY-4360
>                 URL: https://issues.jboss.org/browse/WFLY-4360
>             Project: WildFly
>          Issue Type: Task
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Alpha1
>
>
> Completely remove the JAR and its module from the application server.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2824) Remove
 https://issues.apache.org/jira/browse/DIRAPI-125 workaround
In-Reply-To: <JIRA.12530511.1390926661000@Atlassian.JIRA>
References: <JIRA.12530511.1390926661000@Atlassian.JIRA>
	<JIRA.12530511.1390926661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530511.1390926661000.89169.1512577294347@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-2824.
----------------------------


> Remove https://issues.apache.org/jira/browse/DIRAPI-125 workaround 
> -------------------------------------------------------------------
>
>                 Key: WFLY-2824
>                 URL: https://issues.jboss.org/browse/WFLY-2824
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Alpha6
>
>
> As a workaround for an Apache DS bug (https://issues.apache.org/jira/browse/DIRAPI-125) we forked their LdapUrl class in the testsuite/integration/basic module. This JIRA is a reminder to check if the upstream bug is fixed and the fix is in the release WF uses; if so remove the workaround.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5243) Extended access log support
In-Reply-To: <JIRA.12583360.1441085512000@Atlassian.JIRA>
References: <JIRA.12583360.1441085512000@Atlassian.JIRA>
	<JIRA.12583360.1441085512000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583360.1441085512000.89173.1512577294420@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5243.
----------------------------


> Extended access log support
> ---------------------------
>
>                 Key: WFLY-5243
>                 URL: https://issues.jboss.org/browse/WFLY-5243
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4978) unable to define
 excluded-connectors attribute for colocated replicated HA topology
In-Reply-To: <JIRA.12578755.1437480898000@Atlassian.JIRA>
References: <JIRA.12578755.1437480898000@Atlassian.JIRA>
	<JIRA.12578755.1437480898000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578755.1437480898000.89179.1512577294587@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4978.
----------------------------


>  unable to define excluded-connectors attribute for colocated replicated HA topology
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-4978
>                 URL: https://issues.jboss.org/browse/WFLY-4978
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha6
>
>
> When list of connectors is defined in excluded-connectors atribute EAP throws this exception:
> WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "messaging-activemq"),
>     ("server" => "default")
> ]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:136) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> 	at org.jboss.dmr.ModelNode.keys(ModelNode.java:1373) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> 	at org.wildfly.extension.messaging.activemq.ha.ReplicationColocatedDefinition.buildConfiguration(ReplicationColocatedDefinition.java:114)
> 	at org.wildfly.extension.messaging.activemq.ha.HAPolicyConfigurationBuilder.addHAPolicyConfiguration(HAPolicyConfigurationBuilder.java:71)
> 	at org.wildfly.extension.messaging.activemq.ServerAdd.transformConfig(ServerAdd.java:390)
> 	at org.wildfly.extension.messaging.activemq.ServerAdd.access$100(ServerAdd.java:139)
> 	at org.wildfly.extension.messaging.activemq.ServerAdd$3.execute(ServerAdd.java:195)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:820) [wildfly-controller-2.0.0.Alpha9.jar:2.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:611) [wildfly-controller-2.0.0.Alpha9.jar:2.0.0.Alpha9]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:355) [wildfly-controller-2.0.0.Alpha9.jar:2.0.0.Alpha9]
> 	at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) [wildfly-controller-2.0.0.Alpha9.jar:2.0.0.Alpha9]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> cli command: ":write-attribute(name=excluded-connectors, value=["http-connector"])"



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 11:21:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4679) Upgrade Infinispan to
	7.2.2.Final
In-Reply-To: <JIRA.12572863.1432675976000@Atlassian.JIRA>
References: <JIRA.12572863.1432675976000@Atlassian.JIRA>
	<JIRA.12572863.1432675976000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572863.1432675976000.89184.1512577294690@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4679.
----------------------------


> Upgrade Infinispan to 7.2.2.Final
> ---------------------------------
>
>                 Key: WFLY-4679
>                 URL: https://issues.jboss.org/browse/WFLY-4679
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha2
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:34 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4625) EJB
 SecurityContextInterceptor attempts JAAS login which doesn't work for
 JASPIC authentications
In-Reply-To: <JIRA.12497662.1375264697000@Atlassian.JIRA>
References: <JIRA.12497662.1375264697000@Atlassian.JIRA>
	<JIRA.12497662.1375264697000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497662.1375264697000.89189.1512577294828@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4625.
----------------------------


> EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4625
>                 URL: https://issues.jboss.org/browse/WFLY-4625
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: arjan tijms
>            Assignee: Stefan Guilhen
>              Labels: authentication, ejb, jaspi, jaspic, security, security-context
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha2
>
>
> After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
> The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
> This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
> However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
> The problematic part in {{SimpleSecurityManager}}:
> {code}
> public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
>         boolean contextPushed = false;
>         boolean securityContextEstablished = false;
>         final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
>         try {
>             contexts.push(previous);
>             contextPushed = true;
>             SecurityContext current = establishSecurityContext(securityDomain);
>             securityContextEstablished = true;
>             if (previous != null) {
>                 current.setSubjectInfo(previous.getSubjectInfo());
>                 current.setIncomingRunAs(previous.getOutgoingRunAs());
>             }
>             RunAs currentRunAs = current.getIncomingRunAs();
>             boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
>             if (trusted == false) {
>               
>                 boolean authenticated = false;
>                 if (SecurityActions.remotingContextIsSet()) {
>                     // ...
>                 }
>                 // If we have a trusted identity no need for a re-auth.                
>                 if (authenticated == false) {
>                     // THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
>                     authenticated = authenticate(current, null);
>                 }
> {code}
> The (condensed) stack that will lead to an exception is the following:
> {noformat}
> javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
> org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
> {noformat}
> Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
> Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4995) Upgrade HAL to 2.8.3
In-Reply-To: <JIRA.12579055.1437649056000@Atlassian.JIRA>
References: <JIRA.12579055.1437649056000@Atlassian.JIRA>
	<JIRA.12579055.1437649056000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579055.1437649056000.89197.1512577295092@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4995.
----------------------------


> Upgrade HAL to 2.8.3
> --------------------
>
>                 Key: WFLY-4995
>                 URL: https://issues.jboss.org/browse/WFLY-4995
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.Alpha6
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5292) Missleading link to console
 from Wildfly10 homepage in domain mode
In-Reply-To: <JIRA.12584203.1441700157000@Atlassian.JIRA>
References: <JIRA.12584203.1441700157000@Atlassian.JIRA>
	<JIRA.12584203.1441700157000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584203.1441700157000.89201.1512577295285@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5292.
----------------------------


> Missleading link to console from Wildfly10 homepage in domain mode
> ------------------------------------------------------------------
>
>                 Key: WFLY-5292
>                 URL: https://issues.jboss.org/browse/WFLY-5292
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server, Web Console
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Pavel Jelinek
>            Assignee: Darran Lofthouse
>            Priority: Minor
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4917) Invalid context set up for
	batch threads
In-Reply-To: <JIRA.12577921.1436817018000@Atlassian.JIRA>
References: <JIRA.12577921.1436817018000@Atlassian.JIRA>
	<JIRA.12577921.1436817018000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577921.1436817018000.89204.1512577295414@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4917.
----------------------------


> Invalid context set up for batch threads
> ----------------------------------------
>
>                 Key: WFLY-4917
>                 URL: https://issues.jboss.org/browse/WFLY-4917
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 10.0.0.Alpha6
>
>
> Batch tasks incorrectly set-up the contexts needed for the executed tasks. The task needs to be set-up outside the new thread.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4997) Upgrade jboss-transaction-spi
In-Reply-To: <JIRA.12579179.1437658995000@Atlassian.JIRA>
References: <JIRA.12579179.1437658995000@Atlassian.JIRA>
	<JIRA.12579179.1437658995000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579179.1437658995000.89210.1512577295578@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4997.
----------------------------


> Upgrade jboss-transaction-spi
> -----------------------------
>
>                 Key: WFLY-4997
>                 URL: https://issues.jboss.org/browse/WFLY-4997
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Minor
>             Fix For: 10.0.0.Beta1
>
>
> We have just released 7.3.0.Final which introduced a locator method for obtaining an implementation of the TransactionListenerRegistry interface that JPA uses to monitor thread to transaction association changes.
> The upgrade also pulls in 7.2.0.Final which introduced a change to make ServerVMClientUserTransaction implement javax.naming.Referenceable (so that it can be looked up via JNDI).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4715) Webservices subsystem
 requires reload when it does not actually need to
In-Reply-To: <JIRA.12573475.1433188269000@Atlassian.JIRA>
References: <JIRA.12573475.1433188269000@Atlassian.JIRA>
	<JIRA.12573475.1433188269000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573475.1433188269000.89214.1512577295661@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4715.
----------------------------


> Webservices subsystem requires reload when it does not actually need to
> -----------------------------------------------------------------------
>
>                 Key: WFLY-4715
>                 URL: https://issues.jboss.org/browse/WFLY-4715
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Web Services
>    Affects Versions: 9.0.0.CR1
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Alpha3
>
>
> When trying undefining and already undefined attribute of the webservices subsystem of a WildFly container on which at least a WS deployment is active, the operation requires reload if the attribute has a default value.
> See http://lists.jboss.org/pipermail/wildfly-dev/2015-June/004013.html for further details.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5281) [Migration operation] [Web to
 Undertow] When migrating SSO configuration path should be defined as "/"
In-Reply-To: <JIRA.12584014.1441370753000@Atlassian.JIRA>
References: <JIRA.12584014.1441370753000@Atlassian.JIRA>
	<JIRA.12584014.1441370753000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584014.1441370753000.89219.1512577295759@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5281.
----------------------------


> [Migration operation] [Web to Undertow] When migrating SSO configuration path should be defined as "/"
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5281
>                 URL: https://issues.jboss.org/browse/WFLY-5281
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radim Hatlapatka
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.CR1
>
>
> When using SSO with JBoss Web all contexts are authenticated via SSO. In case of Undertow by default are only those with the same context name.
> As such {{:migrate}} operation should define {{path=/}} when migrating SSO configuration as that makes the behaviour the same as it was in JBoss Web and thus having the server configured equivalently.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5192) XTSSubsystemDefinition says
 HOST attribute doesn't allow null, but it should
In-Reply-To: <JIRA.12582366.1440430270000@Atlassian.JIRA>
References: <JIRA.12582366.1440430270000@Atlassian.JIRA>
	<JIRA.12582366.1440430270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582366.1440430270000.89224.1512577295845@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5192.
----------------------------


> XTSSubsystemDefinition says HOST attribute doesn't allow null, but it should
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5192
>                 URL: https://issues.jboss.org/browse/WFLY-5192
>             Project: WildFly
>          Issue Type: Bug
>          Components: XTS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 10.0.0.CR1
>
>
> The xsd for the xts subsystem says the "host" element is not required, and the parser behaves accordingly, but the HOST attribute in XTSSubsystemDefinition says the attribute doesn't allow null, while simultaneously configuring a default value for it.
> Setting a default value for an attribute is pointless if it doesn't allow null; the default value is what the runtime services will use if the persistent config value is null.
> This situation prevents booting of legacy xml configs using schema versions that predate the "host element. (Specifically, EAP 6 configs.) The boot validates the entire config to ensure that required attributes are configured, and that validation fails. Booting configs that conform to the current schema would fail too if "host" was not present.
> This should be a simple one line change.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:35 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5088) [Migration operation] If
 acceptor has set factory-class
 org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory then migration
 operation does not translate it to Artemis equivalent
In-Reply-To: <JIRA.12580959.1439376584000@Atlassian.JIRA>
References: <JIRA.12580959.1439376584000@Atlassian.JIRA>
	<JIRA.12580959.1439376584000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580959.1439376584000.89229.1512577295932@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5088.
----------------------------


> [Migration operation] If acceptor has set factory-class org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory then migration operation does not translate it to Artemis equivalent
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5088
>                 URL: https://issues.jboss.org/browse/WFLY-5088
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Beta2
>
>
> This is the same problem as reported with connectors in JBEAP-638.
> org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory should be migrated to equivalent org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:36 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5014) jms-bridge source and target
 context properties can not be parsed
In-Reply-To: <JIRA.12579465.1438007308000@Atlassian.JIRA>
References: <JIRA.12579465.1438007308000@Atlassian.JIRA>
	<JIRA.12579465.1438007308000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579465.1438007308000.89234.1512577296025@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5014.
----------------------------


> jms-bridge source and target context properties can not be parsed
> -----------------------------------------------------------------
>
>                 Key: WFLY-5014
>                 URL: https://issues.jboss.org/browse/WFLY-5014
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Beta2
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:36 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5108) SingletonService can start
 multiple master nodes if election policies are not identical
In-Reply-To: <JIRA.12581250.1439575148000@Atlassian.JIRA>
References: <JIRA.12581250.1439575148000@Atlassian.JIRA>
	<JIRA.12581250.1439575148000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581250.1439575148000.89239.1512577296153@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5108.
----------------------------


> SingletonService can start multiple master nodes if election policies are not identical
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-5108
>                 URL: https://issues.jboss.org/browse/WFLY-5108
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta2
>
>
> Currently, the the singleton master election occurs on every node, and nodes that detect if they have won the election will start the service.  If the election policy is non-deterministic, or not identical on every node, then there is a possibility that multiple singleton services could start.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:36 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4823) Some Undertow filters do not
 handle predicates properly
In-Reply-To: <JIRA.12576018.1435066626000@Atlassian.JIRA>
References: <JIRA.12576018.1435066626000@Atlassian.JIRA>
	<JIRA.12576018.1435066626000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576018.1435066626000.89243.1512577296311@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4823.
----------------------------


> Some Undertow filters do not handle predicates properly
> -------------------------------------------------------
>
>                 Key: WFLY-4823
>                 URL: https://issues.jboss.org/browse/WFLY-4823
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha4
>
>
> The error page and rewrite filters do not use the predicate correctly



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:36 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5067) Ensure proper WS dependencies
 order in org.wildfly:wildfly-feature-pack
In-Reply-To: <JIRA.12580556.1438894663000@Atlassian.JIRA>
References: <JIRA.12580556.1438894663000@Atlassian.JIRA>
	<JIRA.12580556.1438894663000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580556.1438894663000.89247.1512577296397@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5067.
----------------------------


> Ensure proper WS dependencies order in org.wildfly:wildfly-feature-pack
> -----------------------------------------------------------------------
>
>                 Key: WFLY-5067
>                 URL: https://issues.jboss.org/browse/WFLY-5067
>             Project: WildFly
>          Issue Type: Task
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 10.0.0.Beta1
>
>
> Apache CXF and JBossWS both provide an implementation of javax.xml.ws.spi.Provider, which is basically the entry point for a JAX-WS client API implementation.
> As a consequence, unless endorsing is expected to be used, the JBossWS jars need to come before the Apache CXF ones when defining a flat classpath meant to be used by JAX-WS clients applications.
> Currently, the WildFly integration testsuite relies on a flat classpath derived from the maven dependency tree of org.wildfly:wildfly-feature-pack, which hence need to be properly tuned.
> This is of course not a problem at all in-container on WildFly, as proper module dependencies are already in place and defining the classloaders. Same reasoning applies for those relying on the org,jboss.ws.cxf:jbossws-cxf-client dependency only (as that pulls the whole JBossWS-CXf and Apache CXF dependency tree in the proper order), instead of explicitly declaring single dependencies without allowing transitive dependencies (as it's done in wildfly-feature-pack).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:36 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4654) JGroups transport type can't
	be set
In-Reply-To: <JIRA.12572368.1432207670000@Atlassian.JIRA>
References: <JIRA.12572368.1432207670000@Atlassian.JIRA>
	<JIRA.12572368.1432207670000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572368.1432207670000.89252.1512577296501@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4654.
----------------------------


> JGroups transport type can't be set
> -----------------------------------
>
>                 Key: WFLY-4654
>                 URL: https://issues.jboss.org/browse/WFLY-4654
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Alpha3
>
>
> I'm trying to set transport type for JGroups UDP transport. After successful setting via CLI (or model node) and reload, this value is reverted back to undefined.
> [standalone at localhost:9990 transport=UDP] :write-attribute(name="type" ,value="TUNNEL")
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> [standalone at localhost:9990 transport=UDP] ls
> property                              diagnostics-socket-binding=undefined  oob-executor=undefined                shared=false                          thread-factory=undefined              
> thread-pool                           machine=undefined                     properties=[]                         site=undefined                        timer-executor=undefined              
> default-executor=undefined            module=org.jgroups                    rack=undefined                        socket-binding=jgroups-udp            type=undefined   



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:36 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4933) Upgrade jberet-core to
	1.2.0.Alpha2
In-Reply-To: <JIRA.12578208.1436986474000@Atlassian.JIRA>
References: <JIRA.12578208.1436986474000@Atlassian.JIRA>
	<JIRA.12578208.1436986474000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578208.1436986474000.89256.1512577296621@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4933.
----------------------------


> Upgrade jberet-core to 1.2.0.Alpha2
> -----------------------------------
>
>                 Key: WFLY-4933
>                 URL: https://issues.jboss.org/browse/WFLY-4933
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Batch
>            Reporter: Cheng Fang
>            Assignee: James Perkins
>             Fix For: 10.0.0.Beta1
>
>
> 1.2.0.Alpha2:
> https://issues.jboss.org/browse/JBERET/fixforversion/12327492/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
> 1.2.0.Alpha1:
> https://issues.jboss.org/browse/JBERET/fixforversion/12326900/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:36 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3290) Cannot use a cluster name
	other than "ejb"
In-Reply-To: <JIRA.12539127.1398446007000@Atlassian.JIRA>
References: <JIRA.12539127.1398446007000@Atlassian.JIRA>
	<JIRA.12539127.1398446007000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539127.1398446007000.89266.1512577296903@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-3290.
----------------------------


> Cannot use a cluster name other than "ejb"
> ------------------------------------------
>
>                 Key: WFLY-3290
>                 URL: https://issues.jboss.org/browse/WFLY-3290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Chris Stillwell
>            Assignee: Richard Achmatowicz
>            Priority: Critical
>             Fix For: 10.0.0.CR1
>
>         Attachments: helloworld-test.zip
>
>
> When deploying a clustered session bean the cluster will form only if the cluster name is "ejb".   If the standalone-ha.xml is modified to use a different cluster name then the cluster will not form.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5234) Use of
 ModelNode.asPropertyList() is slow when marshaling potentially large
 subsystem model chunks
In-Reply-To: <JIRA.12583192.1440800194000@Atlassian.JIRA>
References: <JIRA.12583192.1440800194000@Atlassian.JIRA>
	<JIRA.12583192.1440800194000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583192.1440800194000.89277.1512577297202@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5234.
----------------------------


> Use of ModelNode.asPropertyList() is slow when marshaling potentially large subsystem model chunks
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5234
>                 URL: https://issues.jboss.org/browse/WFLY-5234
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA, JMS, Security
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 10.0.0.CR1
>
>
> ModelNode.asPropertyList() results in a clone of the model node. If the node is very large this can be expensive.
> We use this call quite a bit in subsystem xml marshallers. The cost is not likely to be significant in most places, but in a few cases where users may end up adding a large number of nodes of a particular type, moving away from this call to another idiom that doesn't involve cloning may help with performance.
> I've heard of a user planning to add thousands of datasources, for example, and wanting very fast performance of the write ops to add those.
> Things I plan to look at:
> (xa-)datasources
> messaging destinations
> resource adapters
> JCA connectors
> security domains



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5051) Requests for persistent
 sessions always trigger replication
In-Reply-To: <JIRA.12580182.1438620601000@Atlassian.JIRA>
References: <JIRA.12580182.1438620601000@Atlassian.JIRA>
	<JIRA.12580182.1438620601000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580182.1438620601000.89284.1512577297370@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5051.
----------------------------


> Requests for persistent sessions always trigger replication
> -----------------------------------------------------------
>
>                 Key: WFLY-5051
>                 URL: https://issues.jboss.org/browse/WFLY-5051
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Beta1
>
>
> For persistent sessions, we trigger session session activation events after a successful SessionManager.findSession(...).  However, this is currently triggered using a Session instance, instead of an ImmutableSession instance, which causes iteration over session attributes to trigger replication of the session at the end of the request - even when the user does not access any mutable session attributes.
> The same is true for Session.close() (via session passivation event).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4660) Infinispan cache store
 properties are not applied
In-Reply-To: <JIRA.12572439.1432244012000@Atlassian.JIRA>
References: <JIRA.12572439.1432244012000@Atlassian.JIRA>
	<JIRA.12572439.1432244012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572439.1432244012000.89287.1512577297427@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4660.
----------------------------


> Infinispan cache store properties are not applied
> -------------------------------------------------
>
>                 Key: WFLY-4660
>                 URL: https://issues.jboss.org/browse/WFLY-4660
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha2
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5314) Upgrade JGroups to 3.6.6.Final
In-Reply-To: <JIRA.12584449.1441815770000@Atlassian.JIRA>
References: <JIRA.12584449.1441815770000@Atlassian.JIRA>
	<JIRA.12584449.1441815770000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584449.1441815770000.89292.1512577297515@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5314.
----------------------------


> Upgrade JGroups to 3.6.6.Final
> ------------------------------
>
>                 Key: WFLY-5314
>                 URL: https://issues.jboss.org/browse/WFLY-5314
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.CR1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2160) Allow Expression for
 datasource subsystem enabled property
In-Reply-To: <JIRA.12501556.1380149025000@Atlassian.JIRA>
References: <JIRA.12501556.1380149025000@Atlassian.JIRA>
	<JIRA.12501556.1380149025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501556.1380149025000.89301.1512577297680@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-2160.
----------------------------


> Allow Expression for datasource subsystem enabled property
> ----------------------------------------------------------
>
>                 Key: WFLY-2160
>                 URL: https://issues.jboss.org/browse/WFLY-2160
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: wildfly
>             Fix For: 10.0.0.Beta1
>
>
> Currently the datasource sub system does not allow expressions. I would like to be able to do this: <datasource jta="true" jndi-name="java:/ds1DS" pool-name="ds1DS" enabled="${ds1.enabled}" use-java-context="true" use-ccm="true"> and set the ds1.enabled property via a properties file.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5196) Downgrade PicketLink to
	2.5.5.CR1
In-Reply-To: <JIRA.12582424.1440493867000@Atlassian.JIRA>
References: <JIRA.12582424.1440493867000@Atlassian.JIRA>
	<JIRA.12582424.1440493867000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582424.1440493867000.89309.1512577297846@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5196.
----------------------------


> Downgrade PicketLink to 2.5.5.CR1
> ---------------------------------
>
>                 Key: WFLY-5196
>                 URL: https://issues.jboss.org/browse/WFLY-5196
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Build System
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: 10.0.0.CR1
>
>
> We have to downgrade PicketLink to 2.5.x to be in sync with EAP 7 and deprecation of PicketLink in WildFly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:37 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:37 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4759) Add direct support for
 redirects and rewrites to the config
In-Reply-To: <JIRA.12574301.1433834296000@Atlassian.JIRA>
References: <JIRA.12574301.1433834296000@Atlassian.JIRA>
	<JIRA.12574301.1433834296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574301.1433834296000.89313.1512577297918@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4759.
----------------------------


> Add direct support for redirects and rewrites to the config
> -----------------------------------------------------------
>
>                 Key: WFLY-4759
>                 URL: https://issues.jboss.org/browse/WFLY-4759
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha4
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:38 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4760) basic-auth handler as
 configured in the subsystem is broken
In-Reply-To: <JIRA.12574302.1433834520000@Atlassian.JIRA>
References: <JIRA.12574302.1433834520000@Atlassian.JIRA>
	<JIRA.12574302.1433834520000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574302.1433834520000.89317.1512577298034@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4760.
----------------------------


> basic-auth handler as configured in the subsystem is broken
> -----------------------------------------------------------
>
>                 Key: WFLY-4760
>                 URL: https://issues.jboss.org/browse/WFLY-4760
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Alpha6
>
>
> This should either be removed or fixed



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:38 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5077) javax.servlet.jstl.api module
 is not properly added for all appropriate deployments.
In-Reply-To: <JIRA.12580905.1439330909000@Atlassian.JIRA>
References: <JIRA.12580905.1439330909000@Atlassian.JIRA>
	<JIRA.12580905.1439330909000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580905.1439330909000.89322.1512577298169@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5077.
----------------------------


> javax.servlet.jstl.api module is not properly added for all appropriate deployments.
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-5077
>                 URL: https://issues.jboss.org/browse/WFLY-5077
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 10.0.0.Beta2
>
>
> If you have non war module that uses JSLT api and remove JSF subsystem deployment will fail with CNFE



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:38 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5263) MBeanServer returns MBean
 names that do not match filter
In-Reply-To: <JIRA.12579474.1438008828000@Atlassian.JIRA>
References: <JIRA.12579474.1438008828000@Atlassian.JIRA>
	<JIRA.12579474.1438008828000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579474.1438008828000.89327.1512577298306@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5263.
----------------------------


> MBeanServer returns MBean names that do not match filter
> --------------------------------------------------------
>
>                 Key: WFLY-5263
>                 URL: https://issues.jboss.org/browse/WFLY-5263
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Thomas Diesler
>            Assignee: Kabir Khan
>             Fix For: 10.0.0.CR1
>
>
> This code
> {code}
>             MBeanServer server = ManagementFactory.getPlatformMBeanServer();
>             for (ObjectName oname : server.queryNames(new ObjectName("*:type=context,*"), null)) {
>                 System.out.println(oname);
>             }
> {code}
> gives 
> {code}
> 16:51:25,842 INFO  [stdout] (pool-3-thread-1) org.apache.camel:context=swagger-test,type=context,name="swagger-test"
> 16:51:25,842 INFO  [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEServer,name=default
> 16:51:25,843 INFO  [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=JVM,name=default,J2EEServer=default
> 16:51:25,843 INFO  [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEDomain,name=jboss.jsr77
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:38 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4455) JSP function lookup is broken
 if EL expression contains map or set literal
In-Reply-To: <JIRA.12566626.1427120281000@Atlassian.JIRA>
References: <JIRA.12566626.1427120281000@Atlassian.JIRA>
	<JIRA.12566626.1427120281000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566626.1427120281000.89332.1512577298420@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4455.
----------------------------


> JSP function lookup is broken if EL expression contains map or set literal
> --------------------------------------------------------------------------
>
>                 Key: WFLY-4455
>                 URL: https://issues.jboss.org/browse/WFLY-4455
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.2.0.Final
>            Reporter: Paul Pogonyshev
>            Assignee: Tomaz Cerar
>              Labels: el, jsp, taglib
>             Fix For: 10.0.0.Alpha3
>
>         Attachments: jsp-bug.war, jsp-bug.war
>
>
> The attached trivial applications consists of 'test.jsp' and 'WEB-INF/bug.tld' files. The latter includes only one function mapped from the standard Java library. It is not relevant what it does, only that it is mapped. File 'test.jsp' contains this expession:
>     ${{}; bug:dummy()}
> Please note that without '{};' (if it is removed or e.g. replaced with '1;) it works correctly, printing something like 'java.lang.Runtime at ...'. (In my real application this is 'my:function1 ({ x: y }) && my:function2 (...)'. Lookup of the first function succeeds, but lookup of the second one fails. If I replace map literal with something else, expression is compiled just fine.)
> However, if expression contains set (or map) literal, JSP compiler fails with this exception:
> {noformat}
> 15:05:24,317 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jsp-bug/test.jsp: org.apache.jasper.JasperException: JBWEB004038: An exception occurred processing JSP page /test.jsp at line 7
> 4:   </head>
> 5: 
> 6:   <body>
> 7:     ${{}; bug:dummy()}
> 8:   </body>
> 9: </html>
> Stacktrace:
>         at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:494) [jastow-1.0.0.Final.jar:1.0.0.Final]
>         at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:408) [jastow-1.0.0.Final.jar:1.0.0.Final]
>         at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
>         at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.Final.jar:1.0.0.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 io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>         at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
> Caused by: java.lang.NullPointerException
>         at org.apache.jasper.el.FunctionMapperImpl.resolveFunction(FunctionMapperImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
>         at com.sun.el.lang.FunctionMapperFactory.resolveFunction(FunctionMapperFactory.java:71) [javax.el-3.0.1-b05.jar:]
>         at com.sun.el.lang.ExpressionBuilder.visit(ExpressionBuilder.java:272) [javax.el-3.0.1-b05.jar:]
>         at com.sun.el.parser.SimpleNode.accept(SimpleNode.java:172) [javax.el-3.0.1-b05.jar:]
>         at com.sun.el.parser.SimpleNode.accept(SimpleNode.java:175) [javax.el-3.0.1-b05.jar:]
>         at com.sun.el.lang.ExpressionBuilder.prepare(ExpressionBuilder.java:227) [javax.el-3.0.1-b05.jar:]
>         at com.sun.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:238) [javax.el-3.0.1-b05.jar:]
>         at com.sun.el.lang.ExpressionBuilder.createValueExpression(ExpressionBuilder.java:295) [javax.el-3.0.1-b05.jar:]
>         at com.sun.el.ExpressionFactoryImpl.createValueExpression(ExpressionFactoryImpl.java:112) [javax.el-3.0.1-b05.jar:]
>         at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:897) [jastow-1.0.0.Final.jar:1.0.0.Final]
>         at org.apache.jsp.test_jsp._jspService(test_jsp.java:61)
>         at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.0.0.Final.jar:1.0.0.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 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.0.0.Final.jar:1.0.0.Final]
>         ... 29 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:38 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 6 Dec 2017 11:21:38 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2167) Implement stacked rule unit
	invocations
In-Reply-To: <JIRA.12723814.1512577252000@Atlassian.JIRA>
References: <JIRA.12723814.1512577252000@Atlassian.JIRA>
	<JIRA.12723814.1512577252240@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723814.1512577252000.89334.1512577298460@Atlassian.JIRA>

Mario Fusco created DROOLS-2167:
-----------------------------------

             Summary: Implement stacked rule unit invocations
                 Key: DROOLS-2167
                 URL: https://issues.jboss.org/browse/DROOLS-2167
             Project: Drools
          Issue Type: Feature Request
          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 Dec  6 11:27:01 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Wed, 6 Dec 2017 11:27:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.89364.1512577621791@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498170#comment-13498170 ] 

Alberto Gori commented on ELY-1455:
-----------------------------------

Sure:

{code:sql}

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `created_at` datetime NOT NULL,
  `display_name` varchar(30) COLLATE utf8_unicode_ci NOT NULL,
  `email` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `first_name` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
  `last_login` datetime DEFAULT NULL,
  `last_name` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
  `modified_at` datetime NOT NULL,
  `password` char(32) COLLATE utf8_unicode_ci NOT NULL,
  `state` varchar(10) COLLATE utf8_unicode_ci NOT NULL,
  `user_type` varchar(20) COLLATE utf8_unicode_ci NOT NULL,
  `time_zone` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `features` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
  `avatarpath` varchar(250) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `email` (`email`),
  UNIQUE KEY `display_name` (`display_name`),
  KEY `state` (`state`),
  KEY `user_type` (`user_type`)
) ENGINE=InnoDB AUTO_INCREMENT=10919 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE `user_user_group` (
  `user_id` int(10) unsigned NOT NULL,
  `user_group_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`user_id`,`user_group_id`),
  KEY `name` (`user_group_id`),
  CONSTRAINT `user_user_group_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`),
  CONSTRAINT `user_user_group_ibfk_2` FOREIGN KEY (`user_group_id`) REFERENCES `user_group` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=561 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
{code}


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 11:29:00 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Wed, 6 Dec 2017 11:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.89369.1512577740503@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498633#comment-13498633 ] 

Alberto Gori commented on ELY-1455:
-----------------------------------

Also, in another test (let me know if you want to see the sources again), I have removed Richfaces and Prettyfaces and issue is still there.

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 12:12:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 6 Dec 2017 12:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2166) NPE in
 KieModuleMetaDataImpl in projects with invalid pom.xml
In-Reply-To: <JIRA.12723779.1512570655000@Atlassian.JIRA>
References: <JIRA.12723779.1512570655000@Atlassian.JIRA>
	<JIRA.12723779.1512570655000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723779.1512570655000.89523.1512580320310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2166:
--------------------------------
    Sprint: 2017 Week 49-50


> NPE in KieModuleMetaDataImpl in projects with invalid pom.xml
> -------------------------------------------------------------
>
>                 Key: DROOLS-2166
>                 URL: https://issues.jboss.org/browse/DROOLS-2166
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Jan Hrcek
>            Assignee: Mario Fusco
>
> When indexing assets in projects which have some problems with pom.xml (e.g. the parent of that pom can't be resolved), there's the following exception in server.log
> {code:java}
> 14:34:46,627 ERROR [stderr] (Thread-144) java.lang.NullPointerException
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaDataImpl.init(KieModuleMetaDataImpl.java:167)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaDataImpl.<init>(KieModuleMetaDataImpl.java:86)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaData$Factory.newKieModuleMetaData(KieModuleMetaData.java:60)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.backend.builder.core.Builder.getKieModuleMetaDataIgnoringErrors(Builder.java:593)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.backend.builder.service.BuildInfoImpl.getKieModuleMetaDataIgnoringErrors(BuildInfoImpl.java:46)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.ProjectDataModelOracleBuilderProvider.newBuilder(ProjectDataModelOracleBuilderProvider.java:62)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache.makeProjectOracle(LRUProjectDataModelOracleCache.java:80)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache.assertProjectDataModelOracle(LRUProjectDataModelOracleCache.java:72)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache$Proxy$_$$_WeldClientProxy.assertProjectDataModelOracle(Unknown Source)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.DataModelServiceImpl.getProjectDataModel(DataModelServiceImpl.java:91)
> {code}
> The root cause is that kieModule.getPomModel() [here|https://github.com/kiegroup/drools/blob/master/kie-ci/src/main/java/org/kie/scanner/KieModuleMetaDataImpl.java#L167] returns null, because pom model is [not created in this case|https://github.com/kiegroup/drools/blob/master/drools-compiler/src/main/java/org/drools/compiler/kie/builder/impl/AbstractKieModule.java#L374-L388] because it can't be parsed or can't be validated.
> In this case we should at least avoid many NPEs being shown in server.log by doing null check and doing nothing if getPomModel() returns null



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:12:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 6 Dec 2017 12:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2166) NPE in
 KieModuleMetaDataImpl in projects with invalid pom.xml
In-Reply-To: <JIRA.12723779.1512570655000@Atlassian.JIRA>
References: <JIRA.12723779.1512570655000@Atlassian.JIRA>
	<JIRA.12723779.1512570655000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723779.1512570655000.89526.1512580320370@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2166.
---------------------------------
    Resolution: Done


Fixed by https://github.com/kiegroup/drools/commit/a5c753ea0

> NPE in KieModuleMetaDataImpl in projects with invalid pom.xml
> -------------------------------------------------------------
>
>                 Key: DROOLS-2166
>                 URL: https://issues.jboss.org/browse/DROOLS-2166
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Jan Hrcek
>            Assignee: Mario Fusco
>
> When indexing assets in projects which have some problems with pom.xml (e.g. the parent of that pom can't be resolved), there's the following exception in server.log
> {code:java}
> 14:34:46,627 ERROR [stderr] (Thread-144) java.lang.NullPointerException
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaDataImpl.init(KieModuleMetaDataImpl.java:167)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaDataImpl.<init>(KieModuleMetaDataImpl.java:86)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.scanner.KieModuleMetaData$Factory.newKieModuleMetaData(KieModuleMetaData.java:60)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.backend.builder.core.Builder.getKieModuleMetaDataIgnoringErrors(Builder.java:593)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.backend.builder.service.BuildInfoImpl.getKieModuleMetaDataIgnoringErrors(BuildInfoImpl.java:46)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.ProjectDataModelOracleBuilderProvider.newBuilder(ProjectDataModelOracleBuilderProvider.java:62)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache.makeProjectOracle(LRUProjectDataModelOracleCache.java:80)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache.assertProjectDataModelOracle(LRUProjectDataModelOracleCache.java:72)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.cache.LRUProjectDataModelOracleCache$Proxy$_$$_WeldClientProxy.assertProjectDataModelOracle(Unknown Source)
> 14:34:46,627 ERROR [stderr] (Thread-144) 	at org.kie.workbench.common.services.datamodel.backend.server.DataModelServiceImpl.getProjectDataModel(DataModelServiceImpl.java:91)
> {code}
> The root cause is that kieModule.getPomModel() [here|https://github.com/kiegroup/drools/blob/master/kie-ci/src/main/java/org/kie/scanner/KieModuleMetaDataImpl.java#L167] returns null, because pom model is [not created in this case|https://github.com/kiegroup/drools/blob/master/drools-compiler/src/main/java/org/drools/compiler/kie/builder/impl/AbstractKieModule.java#L374-L388] because it can't be parsed or can't be validated.
> In this case we should at least avoid many NPEs being shown in server.log by doing null check and doing nothing if getPomModel() returns null



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:12:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Dec 2017 12:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8656) Bean discovery in deployment
 dependencies (modules) is always interpreted as "all"
In-Reply-To: <JIRA.12689701.1493299528000@Atlassian.JIRA>
References: <JIRA.12689701.1493299528000@Atlassian.JIRA>
	<JIRA.12689701.1493299528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12689701.1493299528000.89531.1512580320514@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8656:
-----------------------------------
    Fix Version/s: 12.0.0.Alpha1


> Bean discovery in deployment dependencies (modules) is always interpreted as "all"
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-8656
>                 URL: https://issues.jboss.org/browse/WFLY-8656
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.1.0.Final, 11.0.0.Beta1
>            Reporter: Yoann Rodi?re
>            Assignee: Martin Kouba
>             Fix For: 12.0.0.Alpha1
>
>
> The CDI spec specifies that the {{beans.xml}} file may set the "bean discovery mode" for a given bean archive: https://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_archive
> Possible values include "all" (all classes should be considered as CDI beans) and "annotated" (only classes with class-level CDI annotations should b considered as CDI beans).
> In Wildfly, this bean discovery mode is taken into account correctly for deployments, but not for the modules they depend on. For those modules, provided there is a {{beans.xml}}, and irrespective of the bean discovery mode set inside this file, every single class is considered as a bean and added to the CDI context.
> ----
> This behavior is not related to the bean discovery mode defined in the "beans.xml" of the deployment. Actually, the code responsible for handling bean discovery in deployments and in their dependency is clearly separated. It seems that {{ExternalBeanArchiveProcessor}} is responsible for bean discovery in dependencies, and this class completely ignores the bean discovery mode defined in the {{bean.xml}} and always populate the archive with every single discovered class:
> {code}
> final BeansXml beansXml = parseBeansXml(url, parser, deploymentUnit);
> final UrlScanner urlScanner = new UrlScanner();
> final List<String> discoveredClasses = new ArrayList<String>();
> if (!urlScanner.handleBeansXml(url, discoveredClasses)) {
>     continue;
> }
> discoveredClasses.removeAll(componentClassNames);
> /*
>  * Below, the archive is populated with every discovered class,
>  * irrespective of beansXML.getBeanDiscoveryMode()
>  */
> final BeanDeploymentArchiveImpl bda = new BeanDeploymentArchiveImpl(new HashSet<String>(discoveredClasses), beansXml, dependency, beanArchiveIdPrefix + url.toExternalForm(), BeanArchiveType.EXTERNAL);
> {code}
> There seems to be hard-coded exceptions for {{jsf-impl-2.2}} and {{resteasy-cdi}}, so I suspect this problem has been noticed before, but I couldn't find any open ticket.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:14:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-622) TS: Option to run under
	security manager.
In-Reply-To: <JIRA.12453254.1322516766000@Atlassian.JIRA>
References: <JIRA.12453254.1322516766000@Atlassian.JIRA>
	<JIRA.12453254.1322516766000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453254.1322516766000.89539.1512580441561@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-622:
----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> TS: Option to run under security manager.
> -----------------------------------------
>
>                 Key: WFLY-622
>                 URL: https://issues.jboss.org/browse/WFLY-622
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Ondrej Zizka
>            Assignee: Peter Skopek
>             Fix For: 8.0.0.Final
>
>
> {code}
> -Dsecurity.manager
> {code}
> and
> {code}
> -Dsecurity.policy
> {code}
> There are some tests failing under globally set SM because they use their own.
> These need to be exluded from running when security manager is in use.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1602) Integrate the picket linke
 console extension with HAL
In-Reply-To: <JIRA.12495288.1372407479000@Atlassian.JIRA>
References: <JIRA.12495288.1372407479000@Atlassian.JIRA>
	<JIRA.12495288.1372407479000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495288.1372407479000.89544.1512580441702@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1602:
-----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Integrate the picket linke console extension with HAL
> -----------------------------------------------------
>
>                 Key: WFLY-1602
>                 URL: https://issues.jboss.org/browse/WFLY-1602
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>             Fix For: 8.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-492) JCA "connector" subsystem
	threads usage
In-Reply-To: <JIRA.12433051.1300304002000@Atlassian.JIRA>
References: <JIRA.12433051.1300304002000@Atlassian.JIRA>
	<JIRA.12433051.1300304002000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12433051.1300304002000.89549.1512580441879@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-492:
----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> JCA "connector" subsystem threads usage
> ---------------------------------------
>
>                 Key: WFLY-492
>                 URL: https://issues.jboss.org/browse/WFLY-492
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1790) RBAC: HostScopedRole*
 operations are wrong (copy&paste from ServerGroupScopedRole*)
In-Reply-To: <JIRA.12497694.1375278644000@Atlassian.JIRA>
References: <JIRA.12497694.1375278644000@Atlassian.JIRA>
	<JIRA.12497694.1375278644000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497694.1375278644000.89553.1512580441996@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1790:
-----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> RBAC: HostScopedRole* operations are wrong (copy&paste from ServerGroupScopedRole*)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1790
>                 URL: https://issues.jboss.org/browse/WFLY-1790
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Ladislav Thon
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Final
>
>
> This is the issue I was speaking about with Brian yesterday.
> The {{HostScopedRole*}} operations are clearly a copy&paste from {{ServerGroupScopedRole*}} operations. Sadly, there are few artifacts of this:
> - {{HostScopedRoleAdd.performRuntime}} refers to attribute definitions from {{ServerGroupScopedRoleResourceDefinition}}, while it should use the ones from {{HostScopedRolesResourceDefinition}}
> - all the {{HostScopedRoleAdd}}, {{HostScopedRoleRemove}} and {{HostScopedRoleWriteAttributeHandler}} operations expect that the {{hosts}} attribute will always contain a valid list, while it can easily be undefined (see {{HostScopedRolesResourceDefinition.HOSTS}})



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-597) TS: Put all management tests
 into one dir (org.jboss.as.test.integration.mgmt)
In-Reply-To: <JIRA.12449418.1318563293000@Atlassian.JIRA>
References: <JIRA.12449418.1318563293000@Atlassian.JIRA>
	<JIRA.12449418.1318563293000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12449418.1318563293000.89557.1512580442109@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-597:
----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> TS: Put all management tests into one dir (org.jboss.as.test.integration.mgmt)
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-597
>                 URL: https://issues.jboss.org/browse/WFLY-597
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>             Fix For: 8.0.0.Final
>
>
> integration/org.jboss.as.test.integration.management
> and further separated by subsystems/interfaces:
> org.jboss.as.test.integration.management.cli
> org.jboss.as.test.integration.management.http
> org.jboss.as.test.integration.management.api
>   org.jboss.as.test.integration.management.api.messaging
> Thanks Dominik for pointing out.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1475) Update to Teiid Extension
	1.1.x
In-Reply-To: <JIRA.12493836.1370613424000@Atlassian.JIRA>
References: <JIRA.12493836.1370613424000@Atlassian.JIRA>
	<JIRA.12493836.1370613424000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493836.1370613424000.89562.1512580442224@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1475:
-----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Update to Teiid Extension 1.1.x
> -------------------------------
>
>                 Key: WFLY-1475
>                 URL: https://issues.jboss.org/browse/WFLY-1475
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1788) RBAC: role combination
	doesn't work
In-Reply-To: <JIRA.12497689.1375277175000@Atlassian.JIRA>
References: <JIRA.12497689.1375277175000@Atlassian.JIRA>
	<JIRA.12497689.1375277175000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497689.1375277175000.89566.1512580442316@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1788:
-----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> RBAC: role combination doesn't work
> -----------------------------------
>
>                 Key: WFLY-1788
>                 URL: https://issues.jboss.org/browse/WFLY-1788
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Ladislav Thon
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Final
>
>
> [This issue was in fact found on 2013-07-02 and is being filled now only for tracking purposes.]
> Combining multiple roles doesn't work, as {{ManagementPermissionCollection(CombinationManagementPermission)}} will never {{imply}} a {{ManagementPermissionCollection(SimpleManagementPermission)}}. See TODOs in {{DefaultPermissionFactory}} and {{ManagementPermissionCollection}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1252) Manage Web Services
 deployment information in the console
In-Reply-To: <JIRA.12449329.1318510246000@Atlassian.JIRA>
References: <JIRA.12449329.1318510246000@Atlassian.JIRA>
	<JIRA.12449329.1318510246000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12449329.1318510246000.89572.1512580442453@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1252:
-----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Manage Web Services deployment information in the console
> ---------------------------------------------------------
>
>                 Key: WFLY-1252
>                 URL: https://issues.jboss.org/browse/WFLY-1252
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: David Bosschaert
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.Final
>
>
> /deployment=mydeployment.jar/subsystem=webservices contains Web Services deployment information which should be made manageable in the console. This should integrate with the overall deployment management views.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-618) TS: (Re-)Create test group for
	web profile.
In-Reply-To: <JIRA.12452340.1321420488000@Atlassian.JIRA>
References: <JIRA.12452340.1321420488000@Atlassian.JIRA>
	<JIRA.12452340.1321420488000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452340.1321420488000.89576.1512580442575@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-618:
----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> TS: (Re-)Create test group for web profile.
> -------------------------------------------
>
>                 Key: WFLY-618
>                 URL: https://issues.jboss.org/browse/WFLY-618
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Ondrej Zizka
>             Fix For: 8.0.0.Final
>
>
> (20:46:10) Nihility: OndrejZizka: got a few seconds to talk testsuite
> (20:46:10) smcgowan: baileyje: http://pastebin.test.redhat.com/67894
> (20:46:20) OndrejZizka: Nihility: Sure
> (20:46:23) jharting opustil m?stnost (quit: Quit: Leaving.).
> (20:46:54) Nihility: OndrejZizka: ok so for the beta release i need to resurect the old default profile "the web profile" and make the existing one the "full" profile
> (20:47:17) Nihility: OndrejZizka: i had some long conversations with various folks about how to do that without screwing up the progress that has already been made with the testsuite
> (20:48:06) Nihility: OndrejZizka: it seems that the best solution was to have a property which tells the testsuite to run against the "web" profile, using the different config, and also disabling tests using a pattern match
> (20:48:27) Nihility: OndrejZizka: so basically we would have to manually kick off a web run, or have a hudson run or something
> (20:49:04) Nihility: OndrejZizka: did you have any thoughts on that? I had originally hoped we would use different configs for different tests, but that seems to be a nightmare in our current maven configuration
> (20:49:28) Nihility: OndrejZizka: or any other ideas would be welcome
> (20:49:32) OndrejZizka: Nihility:  Have you seen my last post in jboss-as7-dev?
> (20:49:59) OndrejZizka: Nihility:  I have modified the testsuite a bit, so I believe this task is easier to do with it now too,
> (20:50:07) OndrejZizka: I only need someone to fix OSGi tests
> (20:50:41) Nihility: OndrejZizka: all i have is "printing project number"
> (20:50:42) OndrejZizka: After that, web profile vs. full profile can be simply a profile activating different modules
> (20:51:35) OndrejZizka: Nihility: Forwarded
> (20:51:46) Nihility: OndrejZizka: i mean do you think the different config per test module is reasonable?
> (20:51:59) Nihility: OndrejZizka: it seemed like we would have to do a BIG resturcturing for that
> (20:52:23) OndrejZizka: Nihility: Depends on what are the differences, and for which modules,
> (20:52:45) OndrejZizka: Inside the integration module, the differences are not significant,
> (20:53:01) OndrejZizka: the modules are used to separate tests virtually
> (20:53:07) Nihility: OndrejZizka: yeah thats the sisue the integration module mixes full and non-full
> (20:53:59) OndrejZizka: Nihility:  Could you send me a list of which modules are non-full? And also, the config for web AS profile
> (20:54:15) OndrejZizka: or a list of differences
> (20:54:40) Nihility: OndrejZizka: im working under the assumption we have to run twice (i figured there was no time to restructure to that level)
> (20:55:23) Nihility: OndrejZizka: yeah sure, its basically standalone but without jacorb, hornetq, and jaxr
> (20:55:34) Nihility: OndrejZizka: and webservices 
> (20:55:55) OndrejZizka: Twice?  There are two executions of surefire, which is because some tests test some persistent stuff
> (20:56:43) Nihility: OndrejZizka: no i dont mean automatically run twice, i mean the user has to say something like ./build.sh -Dweb-profile or something
> (20:57:01) Nihility: OndrejZizka: to be honest i dont like that solution as much as doing a config per module
> (20:57:28) OndrejZizka: Nihility:  I think this could be solved too
> (20:57:31) Nihility: OndrejZizka: but the config per module sounds like there is just not enough time, we need to get teh beta out this week
> (20:58:20) smcgowan opustil m?stnost (quit: Quit: Leaving).
> (20:59:02) OndrejZizka: Nihility:  Check this
> (20:59:03) OndrejZizka: https://github.com/OndraZizka/jboss-as/tree/TS-modules-tmp/testsuite/integration
> (20:59:29) OndrejZizka: It's basically done, only OSGi tests fail because there's some assumption about relative paths
> (20:59:38) Nihility: ah intersting
> (20:59:47) Nihility: so you use a maven module to activate profiles?
> (20:59:51) OndrejZizka: If someone fixes that, I think we could use that for the requirements you stated
> nickarls Nihility 
> (21:00:13) OndrejZizka: Nihility: and vice versa - this way is the most flexible
> (21:00:47) OndrejZizka: Using profiles, I activate sets of modules, which define -DallTests, or a specific group;
> (21:01:17) OndrejZizka: then, in these modules, there are profiles which can be disabled, and also "global" profiles which change database config etc.
> (21:02:35) Nihility: ah ok so in theory
> (21:02:44) Nihility: we would have a group of "full" tests
> (21:02:47) Nihility: or something
> (21:03:48) OndrejZizka: Nihility: yes
> (21:04:16) OndrejZizka: Either as a module, or as a profile.
> (21:04:24) OndrejZizka: in the integration/basic module
> (21:04:28) OndrejZizka: I'd prefer the second,
> (21:04:43) OndrejZizka: but if it turns out there's some problem with maven, we can fall back to module-based selection
> (21:04:52) OndrejZizka: and they can run both in one run
> (21:05:35) OndrejZizka: I mean, running two executions of same tests using profiles is sometimes troublesome 
> (21:05:52) Nihility: yeah and its time consuming
> nickarls Nihility 
> (21:08:52) OndrejZizka: Nihility: So, do we need to run the web tests twice?
> (21:09:01) OndrejZizka: in this full/non-full scenario
> (21:09:16) OndrejZizka: Or in full, only the complement would be run?
> (21:09:42) OndrejZizka: * complementary tests
> (21:11:12) ctomc [~ctomc at upc.si.94.140.92.246.dc.cable.static.telemach.net] vstoupil do m?stnosti.
> (21:11:19) Nihility: OndrejZizka: well IMO we only need to run the "full-only" tests against standalone-full.xml
> (21:12:25) OndrejZizka: Nihility:  Ok, that should be okay. So I'll prepare a PoC and ping you, okay?
> (21:12:33) OndrejZizka: Which TZ is thomas.diesler at jboss.com in?
> (21:13:03) Nihility: OndrejZizka: ok, hes in munich which i think is GMT+1 
> (21:13:33) Nihility: OndrejZizka: we should chat with stuartdouglas about this as well
> (21:16:11) maxandersen [~Adium at redhat/jboss/maxandersen] vstoupil do m?stnosti.
> (21:16:11) re?im (+v maxandersen) od ChanServ
> (21:16:18) Nihility: OndrejZizka: so according to that email the issue he brings up is that we have duplicate sources?
> (21:17:50) stuartdouglas: I really don't like the 1 big ball of sources thing 
> (21:18:14) stuartdouglas: I think it overcomplicates things, requires additional configuration, and may cause dependency and other problems down the road
> stalep stuartdouglas 
> nickarls Nihility 
> (21:22:56) OndrejZizka: stuartdouglas, Nihility, when such problems arise, there's no problem in separating them
> (21:23:31) OndrejZizka: cd testsuite/integration; mv src/test/java/foo/bar module/src/test/java/foo/bar
> (21:23:38) OndrejZizka: ;-)
> (21:23:57) OndrejZizka: Not counting resources
> (21:24:19) OndrejZizka: But I hope that tests keep their resources well separated 
> (21:24:33) OndrejZizka: As per Jason's recent post to dev list
> (21:26:40) darranl [~darranl at redhat/jboss/darranl] vstoupil do m?stnosti.
> (21:26:40) re?im (+v darranl) od ChanServ
> (21:27:47) OndrejZizka: stuartdouglas: Either way - pushing everything to a single module doesn't work, so the  question is not whether to stay with current or split,
> (21:28:08) OndrejZizka: but whether to split the modules and keeps tests together, or split them "physically"
> (21:28:27) OndrejZizka: I have a) done,  stuart likes b),  can be done too
> (21:28:31) stuartdouglas: I think we should go with splitting them up into different modules, with the relevant source in each module
> (21:28:38) stuartdouglas: it just seems like the simplest approach
> (21:28:49) stuartdouglas: and it is also the 'standard' maven way 
> (21:29:12) stuartdouglas: From your point of view, what are the downsides to doing it this way?
> (21:31:48) CheffPJ [~pmcdonou at 219.sub-75-248-111.myvzw.com] vstoupil do m?stnosti.
> (21:32:26) Nihility: stuartdouglas: OndrejZizka assuming we did the split into smaller finer grained modules, would the activation thing still work (e.g. we create dummy modules that activate the other ones)?
> (21:33:02) Nihility: stuartdouglas: OndrejZizka or would we just use the shell scripts?
> navssurtani1 nickarls Nihility 
> nickarls Nihility 
> (21:33:53) OndrejZizka: Nihility:  The separation needs was the original reason why I started this change
> nickarls Nihility 
> (21:34:25) OndrejZizka: Nihility: So, the activation would be done by activating different profiles, which would include
> (21:34:42) OndrejZizka: <modules> <module>...</module> <module>...</module> <module>...</module> ... </modules>



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:14:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-600) TS: Check tests workdirs
In-Reply-To: <JIRA.12449938.1319113810000@Atlassian.JIRA>
References: <JIRA.12449938.1319113810000@Atlassian.JIRA>
	<JIRA.12449938.1319113810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12449938.1319113810000.89580.1512580442666@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-600:
----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> TS: Check tests workdirs
> ------------------------
>
>                 Key: WFLY-600
>                 URL: https://issues.jboss.org/browse/WFLY-600
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>             Fix For: 8.0.0.Final
>
>
> Some tests (also unit tests) have work dirs in ${basedir}, which leaves garbage after running.
> That should change either to target/work or /tmp/...  (consider what's better).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-593) TS: Tests grouping
In-Reply-To: <JIRA.12449286.1318480301000@Atlassian.JIRA>
References: <JIRA.12449286.1318480301000@Atlassian.JIRA>
	<JIRA.12449286.1318480301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12449286.1318480301000.89585.1512580442768@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-593:
----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> TS: Tests grouping
> ------------------
>
>                 Key: WFLY-593
>                 URL: https://issues.jboss.org/browse/WFLY-593
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Ondrej Zizka
>            Assignee: Honza Br?zdil
>             Fix For: 8.0.0.Final
>
>         Attachments: BooleanExpression.g
>
>
> Decide which mechanism to use to assign the tests into one or multiple groups.
> Posibilities:
> 1)
> {code}
> @Test
> @Category(IntegrationTests.class)
> {code}
> http://weblogs.java.net/blog/johnsmart/archive/2010/04/25/grouping-tests-using-junit-categories-0
> Also, Arquillian itself supports grouping: https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/Categories.java
> 2)
> {code}
> @Ignore
> {code}
> 3) Maven Surefire <includes> and <excludes>



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:14:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1250) Create deployment management
	base view
In-Reply-To: <JIRA.12449332.1318510529000@Atlassian.JIRA>
References: <JIRA.12449332.1318510529000@Atlassian.JIRA>
	<JIRA.12449332.1318510529000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12449332.1318510529000.89590.1512580442903@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1250:
-----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Create deployment management base view
> --------------------------------------
>
>                 Key: WFLY-1250
>                 URL: https://issues.jboss.org/browse/WFLY-1250
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: David Bosschaert
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.Final
>
>
> A base view for navigating through deployments needs to be created. This view should allow for deployment-type specific editors to be hooked in. An example deployment-type specific editor would be a web deployment editor.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-772) It's not possible to add more
 global valves through jboss-cli
In-Reply-To: <JIRA.12481965.1357314260000@Atlassian.JIRA>
References: <JIRA.12481965.1357314260000@Atlassian.JIRA>
	<JIRA.12481965.1357314260000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481965.1357314260000.89595.1512580443090@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-772:
----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> It's not possible to add more global valves through jboss-cli
> -------------------------------------------------------------
>
>                 Key: WFLY-772
>                 URL: https://issues.jboss.org/browse/WFLY-772
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Ondra Chaloupka
>            Assignee: Jean-Frederic Clere
>             Fix For: 8.0.0.Final
>
>
> I wanted to add 2 global valves to web subsystem but it's not possible because the commands produces invalid xml file.
> When you run:
> /subsystem=web/valve=myvalve:add(class-name=org.apache.catalina.valves.RemoteAddrValve,module=org.jboss.as.web,enabled=true)
> /subsystem=web/valve=myvalve2:add(class-name=org.apache.catalina.valves.RemoteAddrValve,module=org.jboss.as.web,enabled=true)
> /:reload
> The reload fails and the xml output saved in standalone.xml file is following:
> {code}
> <valve name="myvalve" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve" enabled="true">
>   <valve name="myvalve2" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve" enabled="true"/>
> </valve>
> {code}
> When I define 2 valves manually to XML file like:
> {code}
> <valve name="myvalve" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve" enabled="true" />
> <valve name="myvalve2" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve" enabled="true" />
> {code}
> then everything works fine.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-491) Add support for roles to be
 read from a properties file.
In-Reply-To: <JIRA.12457244.1327334906000@Atlassian.JIRA>
References: <JIRA.12457244.1327334906000@Atlassian.JIRA>
	<JIRA.12457244.1327334906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457244.1327334906000.89603.1512580443314@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-491:
----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Add support for roles to be read from a properties file.
> --------------------------------------------------------
>
>                 Key: WFLY-491
>                 URL: https://issues.jboss.org/browse/WFLY-491
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-616) TS: Clustering tests - figure
 out how they will be run
In-Reply-To: <JIRA.12451459.1320719018000@Atlassian.JIRA>
References: <JIRA.12451459.1320719018000@Atlassian.JIRA>
	<JIRA.12451459.1320719018000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12451459.1320719018000.89608.1512580443469@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-616:
----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> TS: Clustering tests - figure out how they will be run
> ------------------------------------------------------
>
>                 Key: WFLY-616
>                 URL: https://issues.jboss.org/browse/WFLY-616
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Ondrej Zizka
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Final
>
>
> The current single test is not multinode - when set up as multinode, it fails. So it runs as single node, even though being in package .cluster.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:14:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:14:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-626) TS: Database switch (in
	datasources)
In-Reply-To: <JIRA.12454629.1323729478000@Atlassian.JIRA>
References: <JIRA.12454629.1323729478000@Atlassian.JIRA>
	<JIRA.12454629.1323729478000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12454629.1323729478000.89613.1512580443619@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-626:
----------------------------
    Fix Version/s: 8.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these. From the lastModified date of this issue it looks like it was done for 8.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> TS: Database switch (in datasources)
> ------------------------------------
>
>                 Key: WFLY-626
>                 URL: https://issues.jboss.org/browse/WFLY-626
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>             Fix For: 8.0.0.Final
>
>
> This is how Hibernate did it:
> https://github.com/hibernate/hibernate-core/blob/3.6/hibernate-parent/pom.xml#L575



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3176) Certain file types are
 filtered out and excluded upon deployment
In-Reply-To: <JIRA.12536233.1395886723000@Atlassian.JIRA>
References: <JIRA.12536233.1395886723000@Atlassian.JIRA>
	<JIRA.12536233.1395886723000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536233.1395886723000.89644.1512580810868@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3176:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Certain file types are filtered out and excluded upon deployment
> ----------------------------------------------------------------
>
>                 Key: WFLY-3176
>                 URL: https://issues.jboss.org/browse/WFLY-3176
>             Project: WildFly
>          Issue Type: Bug
>         Environment: Windows 7 x64
>            Reporter: Jason Kim
>             Fix For: 9.0.0.Final
>
>
> In Wildfly 8.0.0, it was possible to deploy a web application with *.less files as well as other custom extensions, but with the latest build (Build #1041), when I  try to deploy an html page that references *.less files, the *.less files are unavailable and I get a 404 error. 
> The same site along with the references to the *.less files worked on 8.0.0 FInal. I tried with other file types, just making up extensions, and Wildfly would not serve the files, instead it would return aa 404 when trying to access them.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4193) Update spec versions on
 Quickstarts README.md files
In-Reply-To: <JIRA.12559913.1418999223000@Atlassian.JIRA>
References: <JIRA.12559913.1418999223000@Atlassian.JIRA>
	<JIRA.12559913.1418999223000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559913.1418999223000.89646.1512580810945@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4193:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Update spec versions on Quickstarts README.md files
> ---------------------------------------------------
>
>                 Key: WFLY-4193
>                 URL: https://issues.jboss.org/browse/WFLY-4193
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Rafael Benevides
>            Assignee: Rafael Benevides
>              Labels: quickstart, quickstarts
>             Fix For: 9.0.0.Final
>
>
> On Every Kitchensink Quickstart, there's a "What is it?" section that contains JAVA EE 6 spec versions. It should be updated to JAVA EE 7.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1454) When logging into the
 management console with no servers defined an error is thrown
In-Reply-To: <JIRA.12493616.1370422325000@Atlassian.JIRA>
References: <JIRA.12493616.1370422325000@Atlassian.JIRA>
	<JIRA.12493616.1370422325000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493616.1370422325000.89651.1512580811205@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1454:
-----------------------------
    Fix Version/s: 9.0.0.Final


>  When logging into the management console with no servers defined an error is thrown
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-1454
>                 URL: https://issues.jboss.org/browse/WFLY-1454
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>              Labels: console_1.5.3, merged
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4289) Authentication bug on one-way
 JAX-WS methods
In-Reply-To: <JIRA.12561749.1422357190000@Atlassian.JIRA>
References: <JIRA.12561749.1422357190000@Atlassian.JIRA>
	<JIRA.12561749.1422357190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561749.1422357190000.89661.1512580811575@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4289:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Authentication bug on one-way JAX-WS methods
> --------------------------------------------
>
>                 Key: WFLY-4289
>                 URL: https://issues.jboss.org/browse/WFLY-4289
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web Services
>    Affects Versions: 8.2.0.Final
>            Reporter: Jakub Grabowski
>            Assignee: Jim Ma
>             Fix For: 9.0.0.Final
>
>
> 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL.
> 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation.
> 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal.
> 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected.
> It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2383) resource-adapter id attribute
 has to match ra name otherwise MDB is not deployed
In-Reply-To: <JIRA.12508785.1382695105000@Atlassian.JIRA>
References: <JIRA.12508785.1382695105000@Atlassian.JIRA>
	<JIRA.12508785.1382695105000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508785.1382695105000.89665.1512580811654@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2383:
-----------------------------
    Fix Version/s: 9.0.0.Final


> resource-adapter id attribute has to match ra name otherwise MDB is not deployed
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2383
>                 URL: https://issues.jboss.org/browse/WFLY-2383
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>
> The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4246) Add test coverage for vaulted
 LDAP credentials in security domains
In-Reply-To: <JIRA.12560819.1421148651000@Atlassian.JIRA>
References: <JIRA.12560819.1421148651000@Atlassian.JIRA>
	<JIRA.12560819.1421148651000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560819.1421148651000.89669.1512580811790@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4246:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Add test coverage for vaulted LDAP credentials in security domains
> ------------------------------------------------------------------
>
>                 Key: WFLY-4246
>                 URL: https://issues.jboss.org/browse/WFLY-4246
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>             Fix For: 9.0.0.Final
>
>
> LdapExtLoginModuleTestCase and LdapExtLikeAdvancedLdapLMTestCase in testsuite/integration/basic should be extended to cover vaulted bindCredentials.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2226) Web Console adds two slashes
 in the address
In-Reply-To: <JIRA.12502291.1381117579000@Atlassian.JIRA>
References: <JIRA.12502291.1381117579000@Atlassian.JIRA>
	<JIRA.12502291.1381117579000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502291.1381117579000.89674.1512580811917@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2226:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Web Console adds two slashes in the address
> -------------------------------------------
>
>                 Key: WFLY-2226
>                 URL: https://issues.jboss.org/browse/WFLY-2226
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jorge Solorzano
>            Assignee: Harald Pehl
>            Priority: Trivial
>             Fix For: 9.0.0.Final
>
>
> The web console adds two slashes to the address after the port
> http://localhost:9990//console/App.html



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3023) JDR CommandLineMain defaults
	to port 9999
In-Reply-To: <JIRA.12533309.1393382553000@Atlassian.JIRA>
References: <JIRA.12533309.1393382553000@Atlassian.JIRA>
	<JIRA.12533309.1393382553000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533309.1393382553000.89678.1512580812148@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3023:
-----------------------------
    Fix Version/s: 9.0.0.Final


> JDR CommandLineMain defaults to port 9999
> -----------------------------------------
>
>                 Key: WFLY-3023
>                 URL: https://issues.jboss.org/browse/WFLY-3023
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Jesse Jaggars
>             Fix For: 9.0.0.Final
>
>
> If the user doesn't provide a port, CommandLineMain defaults to 9999, but with protocol http-remoting. That combo won't work. It should use 9990 since that will be the default management port.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4207) Migrate Quickstarts to Java
	EE 7
In-Reply-To: <JIRA.12560125.1419947482000@Atlassian.JIRA>
References: <JIRA.12560125.1419947482000@Atlassian.JIRA>
	<JIRA.12560125.1419947482000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560125.1419947482000.89681.1512580812209@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4207:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Migrate Quickstarts to Java EE 7
> --------------------------------
>
>                 Key: WFLY-4207
>                 URL: https://issues.jboss.org/browse/WFLY-4207
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 9.0.0.Final
>
>
> Update WildFly Quickstart's code to take advantage of the technologies with major updates on Java EE 7, for instance JAX-RS and JMS.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4060) Intermittent failures on
 SendMessage testcase when running with JTS
In-Reply-To: <JIRA.12556835.1415284509000@Atlassian.JIRA>
References: <JIRA.12556835.1415284509000@Atlassian.JIRA>
	<JIRA.12556835.1415284509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556835.1415284509000.89685.1512580812396@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4060:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Intermittent failures on SendMessage testcase when running with JTS
> -------------------------------------------------------------------
>
>                 Key: WFLY-4060
>                 URL: https://issues.jboss.org/browse/WFLY-4060
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>             Fix For: 9.0.0.Final
>
>
> During testing EAP I was hitting intermittent failures on SendMessageTestscase which was caused by timing issues.
> There is a bit more explanation of reasons at bz: https://bugzilla.redhat.com/show_bug.cgi?id=1160761



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2403) Cannot disable Datasource or
 XADatasource in standalone and domain modes
In-Reply-To: <JIRA.12508938.1383041378000@Atlassian.JIRA>
References: <JIRA.12508938.1383041378000@Atlassian.JIRA>
	<JIRA.12508938.1383041378000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508938.1383041378000.89689.1512580812542@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2403:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Cannot disable Datasource or XADatasource in standalone and domain modes
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2403
>                 URL: https://issues.jboss.org/browse/WFLY-2403
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>
> Description of problem:
> Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload.
> Version-Release number of selected component (if applicable):
> 6.1
> How reproducible:
> Always
> Steps to Reproduce:
> Use the http management interface or the CLI
> 1.Create a Datasource of XADatasource
> 2.Disable it
> 3.The response indicates a server reload is required
> 4.Execute the reload operation
> Actual results:
> The datasource is back to enabled state
> Expected results:
> The datasource should be in disabled state



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3042) There should be a warning
 logged if the default value of node identifier has not been changed.
In-Reply-To: <JIRA.12533608.1393595350000@Atlassian.JIRA>
References: <JIRA.12533608.1393595350000@Atlassian.JIRA>
	<JIRA.12533608.1393595350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533608.1393595350000.89699.1512580812729@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3042:
-----------------------------
    Fix Version/s: 9.0.0.Final


> There should be a warning logged if the default value of node identifier has not been changed.  
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3042
>                 URL: https://issues.jboss.org/browse/WFLY-3042
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Transactions
>    Affects Versions: 8.0.0.Final
>         Environment: JBoss EAP 6.x
>            Reporter: Tom Ross
>            Assignee: Gytis Trikleris
>             Fix For: 9.0.0.Final
>
>
> JBoss EAP instance is using the value of node identifier  to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if  a warning  message was logged at startup telling the user to do it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4521) Deployment does not see /
 cannot access the cdi interceptor if the latter is loaded inside a module
 from a DUP.
In-Reply-To: <JIRA.12568509.1429111042000@Atlassian.JIRA>
References: <JIRA.12568509.1429111042000@Atlassian.JIRA>
	<JIRA.12568509.1429111042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568509.1429111042000.89704.1512580812823@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4521:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Deployment does not see / cannot access the cdi interceptor if the latter is loaded inside  a module from a DUP.
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4521
>                 URL: https://issues.jboss.org/browse/WFLY-4521
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 9.0.0.Beta2
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Jozef Hartinger
>             Fix For: 9.0.0.Final
>
>         Attachments: interceptorExample.jar, interceptorExample.zip
>
>
> The cdi interceptor is not accessible via the deployment, if it is loaded from a Deployment Unit Processor as  a module.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4135) All-in-one Java EE 7
	Quickstart
In-Reply-To: <JIRA.12558337.1417108287000@Atlassian.JIRA>
References: <JIRA.12558337.1417108287000@Atlassian.JIRA>
	<JIRA.12558337.1417108287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558337.1417108287000.89707.1512580813014@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4135:
-----------------------------
    Fix Version/s: 9.0.0.Final


> All-in-one Java EE 7 Quickstart
> -------------------------------
>
>                 Key: WFLY-4135
>                 URL: https://issues.jboss.org/browse/WFLY-4135
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 9.0.0.Final
>
>
> Introduce a WildFly Quickstart to demo usage of the new/updated technologies introduced by Java EE 7. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2537) Write to wsdl-url attribute
 for WS endpoint ends with 'Unknown attribute wsdl-url' instead of
 'Attribute wsdl-url is not writable
In-Reply-To: <JIRA.12525572.1384870529000@Atlassian.JIRA>
References: <JIRA.12525572.1384870529000@Atlassian.JIRA>
	<JIRA.12525572.1384870529000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525572.1384870529000.89711.1512580813116@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2537:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Write to wsdl-url attribute for WS endpoint ends with 'Unknown attribute wsdl-url' instead of 'Attribute wsdl-url is not writable
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2537
>                 URL: https://issues.jboss.org/browse/WFLY-2537
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: R Searls
>            Assignee: R Searls
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> for submission of https://bugzilla.redhat.com/show_bug.cgi?id=987898



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-840) jboss.as MBean subtree missing
 when profiling agent used
In-Reply-To: <JIRA.12486185.1362410448000@Atlassian.JIRA>
References: <JIRA.12486185.1362410448000@Atlassian.JIRA>
	<JIRA.12486185.1362410448000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486185.1362410448000.89718.1512580813367@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-840:
----------------------------
    Fix Version/s: 9.0.0.Final


> jboss.as MBean subtree missing when profiling agent used
> --------------------------------------------------------
>
>                 Key: WFLY-840
>                 URL: https://issues.jboss.org/browse/WFLY-840
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>            Reporter: dpocock
>              Labels: jconsole
>             Fix For: 9.0.0.Final
>
>
> I've set up JBoss 7.1.0.Final as a fresh installation and started standalone
> I can successfully connect with regular jconsole or $JBOSS_HOME/bin/jconsole.  In the MBeans tab, I can see various subtrees, including jboss.as
> Then I stop JBoss and add the jmxetric monitoring agent, as described here:
> http://danielpocock.com/monitoring-jboss-tomcat-and-application-servers-with-jmxetric
> Now, with JBoss running with jmxetric, I connect to it with jconsole (either regular jconsole or $JBOSS_HOME/bin/jconsole) and I can see all the same subtrees, except one, jboss.as is missing.  I can see jboss.modules, jboss.ws, jboss.msc, jboss.jta and core JVM subtrees



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3869) Extend test coverage for
	WFLY-1172
In-Reply-To: <JIRA.12552603.1411049019000@Atlassian.JIRA>
References: <JIRA.12552603.1411049019000@Atlassian.JIRA>
	<JIRA.12552603.1411049019000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552603.1411049019000.89721.1512580813422@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3869:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Extend test coverage for WFLY-1172
> ----------------------------------
>
>                 Key: WFLY-3869
>                 URL: https://issues.jboss.org/browse/WFLY-3869
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Pavel Jelinek
>            Assignee: Pavel Jelinek
>             Fix For: 9.0.0.Final
>
>
> Add test scenario with taglib from module only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2712) Possible NPE in
 RemoteDeployer from WS tests-integration
In-Reply-To: <JIRA.12528666.1389018040000@Atlassian.JIRA>
References: <JIRA.12528666.1389018040000@Atlassian.JIRA>
	<JIRA.12528666.1389018040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528666.1389018040000.89726.1512580813593@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2712:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Possible NPE in RemoteDeployer from WS tests-integration
> --------------------------------------------------------
>
>                 Key: WFLY-2712
>                 URL: https://issues.jboss.org/browse/WFLY-2712
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>            Reporter: Rostislav Svoboda
>            Assignee: Alessio Soldano
>             Fix For: 9.0.0.Final
>
>
> https://github.com/rsvoboda/wildfly/blob/master/webservices/tests-integration/src/main/java/org/jboss/as/webservices/deployer/RemoteDeployer.java#L305  
> Possible NPE, check 'if (options != null)' is present only on line 284.
> Or is it intentional to throw exception ?



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4011) Resource adapter config
 properties cannot be changed without two reloads
In-Reply-To: <JIRA.12555897.1414074950000@Atlassian.JIRA>
References: <JIRA.12555897.1414074950000@Atlassian.JIRA>
	<JIRA.12555897.1414074950000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555897.1414074950000.89730.1512580813730@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4011:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Resource adapter config properties cannot be changed without two reloads
> ------------------------------------------------------------------------
>
>                 Key: WFLY-4011
>                 URL: https://issues.jboss.org/browse/WFLY-4011
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JCA
>    Affects Versions: 8.1.0.Final
>         Environment: Ubuntu 14.0.4 64-bit; JDK 1.8.0_25; Wildfly 8.1.0.Final standalone
>            Reporter: Scott Van Wart
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: cli, resource-adapter
>             Fix For: 9.0.0.Final
>
>         Attachments: remove-add.txt, remove-reload-add.txt
>
>
> I have a RAR deployed within an EAR file and it defines a config property "host" in the resource-adapter subsystem.  I followed the binding instructions here:
> https://docs.jboss.org/author/display/WFLY8/Resource+adapters
> If I want to change the "host" configuration property, I need to do the following:
>   1. Remove the configuration property.
>   2. Reload
>   3. Add the configuration property back.
>   4. Reload
> The "value" attribute of the config property isn't writable (JCA doesn't communicate config property changes during runtime): https://issues.jboss.org/browse/WFLY-3729
> Trying to add the property again after removal results in an error as Wildfly believes the attribute still exists if you haven't reloaded since removal.
> This makes scripting a resource adapter property change difficult, as the "reload" command returns immediately and a script must wait an unknown amount of time for the management interface to become available before it can issue new commands.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:14 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-553) Allow for alternative access
 control providers to be plugged into management.
In-Reply-To: <JIRA.12451179.1320311142000@Atlassian.JIRA>
References: <JIRA.12451179.1320311142000@Atlassian.JIRA>
	<JIRA.12451179.1320311142000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12451179.1320311142000.89742.1512580814195@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-553:
----------------------------
    Fix Version/s: 9.0.0.Final


> Allow for alternative access control providers to be plugged into management.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-553
>                 URL: https://issues.jboss.org/browse/WFLY-553
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: Authorization, Realm_Management
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:14 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1662) SecurityContext API for UI
 Components (especialy ballroom)
In-Reply-To: <JIRA.12495992.1373371675000@Atlassian.JIRA>
References: <JIRA.12495992.1373371675000@Atlassian.JIRA>
	<JIRA.12495992.1373371675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495992.1373371675000.89745.1512580814285@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1662:
-----------------------------
    Fix Version/s: 9.0.0.Final


> SecurityContext API for UI Components (especialy ballroom)
> ----------------------------------------------------------
>
>                 Key: WFLY-1662
>                 URL: https://issues.jboss.org/browse/WFLY-1662
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 9.0.0.Final
>
>
> we need the ability for UI components to access the security context and reason over it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:14 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1560)
 PartialObjectActivationJarTestCase fails if ran after any of
 InflowFlatTestCase or TwoModulesOfDifferentTypeTestCase
In-Reply-To: <JIRA.12494623.1371643659000@Atlassian.JIRA>
References: <JIRA.12494623.1371643659000@Atlassian.JIRA>
	<JIRA.12494623.1371643659000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494623.1371643659000.89750.1512580814440@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1560:
-----------------------------
    Fix Version/s: 9.0.0.Final


> PartialObjectActivationJarTestCase fails if ran after any of InflowFlatTestCase or TwoModulesOfDifferentTypeTestCase
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1560
>                 URL: https://issues.jboss.org/browse/WFLY-1560
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 9.0.0.Final
>
>         Attachments: server_log_snippet.txt
>
>
> PartialObjectActivationJarTestCase fails if it runs after InflowFlatTestCase.  It seems that the {{inflow2}} resource adapter is not fully unregistered by InflowFlatTestCase before PartialObjectActivationJarTestCase begins to start its own RA.
> Here is the server log snippet (DEBUG level):
> http://pastebin.test.redhat.com/147968
> Line 10 of this snippet corresponds to the invocation of {{setConfiguration("basic.xml");}} in PartialObjectActivationJarTestCase. Then, the server is apparently trying to activate {{MultipleConnectionFactory2Impl}} and {{MultipleAdminObject2Impl}} even though these are not involved in {{basic.xml}} of PartialObjectActivationJarTestCase at all. A suspicious exception is on line 19 there. 
> I tried to put some delay between {{remove(address);}} and {{removeModule(defaultPath);}} in {{AbstractModuleDeploymentTestCaseSetup#tearDown()}} but it did not help. I also tried to put {{@Ignore}} to both test methods in the InflowFlatTestCase which also did not help, so it is evidently related only to the RA deployment/undeployment.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:14 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1158) add "remove vault entry"
 option to vault tool
In-Reply-To: <JIRA.12471159.1343221728000@Atlassian.JIRA>
References: <JIRA.12471159.1343221728000@Atlassian.JIRA>
	<JIRA.12471159.1343221728000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471159.1343221728000.89763.1512580814814@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1158:
-----------------------------
    Fix Version/s: 9.0.0.Final


> add "remove vault entry" option to vault tool 
> ----------------------------------------------
>
>                 Key: WFLY-1158
>                 URL: https://issues.jboss.org/browse/WFLY-1158
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Gernot P
>            Assignee: Peter Skopek
>             Fix For: 9.0.0.Final
>
>         Attachments: patch.diff
>
>
> You cannot remove an entry form vault with the vault tool. You can choose only amog following options "0: Store a password  1: Check whether password exists  2: Exit"
> Pleas add "remove password" option to vault tool (vault.sh)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:14 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4382) Functionality to allow
	symbolic links
In-Reply-To: <JIRA.12564026.1424766206000@Atlassian.JIRA>
References: <JIRA.12564026.1424766206000@Atlassian.JIRA>
	<JIRA.12564026.1424766206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564026.1424766206000.89768.1512580814935@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4382:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Functionality to allow symbolic links
> -------------------------------------
>
>                 Key: WFLY-4382
>                 URL: https://issues.jboss.org/browse/WFLY-4382
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>            Reporter: Erdal Yildiz
>            Assignee: Jakub P?cha
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> There should be a possibility to configure that wildfly follows symbolic links.
> Example which describes the problem:
> $wildflyHome/welcome-content/test/index.html --> localhost:8080/test/index.html ==> works.
> $wildflyHome/welcome-content/symlink/index.html --> localhost:8080/symlink/index.html ==> doesn't work.
> "symlink" is the symbolic link which is created by
> ln -s /path/to/symlink $wildflyHome/welcome-content



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:20:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4208) Migrate Quickstarts to JDK 7
In-Reply-To: <JIRA.12560126.1419948024000@Atlassian.JIRA>
References: <JIRA.12560126.1419948024000@Atlassian.JIRA>
	<JIRA.12560126.1419948024000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560126.1419948024000.89771.1512580815051@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4208:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Migrate Quickstarts to JDK 7
> ----------------------------
>
>                 Key: WFLY-4208
>                 URL: https://issues.jboss.org/browse/WFLY-4208
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 9.0.0.Final
>
>
> WildFly Quickstarts are compatible with JDK 7, but still not fully taking advantage of its new language features.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4728) Undertow no confidential port
	is available
In-Reply-To: <JIRA.12573656.1433291737000@Atlassian.JIRA>
References: <JIRA.12573656.1433291737000@Atlassian.JIRA>
	<JIRA.12573656.1433291737000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573656.1433291737000.89776.1512580815260@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4728:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Undertow no confidential port is available
> ------------------------------------------
>
>                 Key: WFLY-4728
>                 URL: https://issues.jboss.org/browse/WFLY-4728
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.0.CR1
>         Environment: Java application server: wildfly-9.0.0.CR1
> Java Development Kit (JDK): 1.7.0_04
> OS: Windows 7 (x64)
>            Reporter: David Zukerman
>            Assignee: Stuart Douglas
>              Labels: security, security-constraint, undertow
>             Fix For: 9.0.0.Final
>
>
> I configured my application's web.xml file to handle all calls through https:
>     <security-constraint>                        
>         <web-resource-collection>
>             <web-resource-name>All resources</web-resource-name>
>             <url-pattern>/*</url-pattern>
>         </web-resource-collection>        
>         <user-data-constraint>
>             <description>SSL</description>
>             <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>         </user-data-constraint>   		
>     </security-constraint>
> I configured WildFly 9.0.0 CR1 to handle https request on the 443 port:
> <socket-binding name="https" port="${jboss.https.port:443}"/>
> <security-realm name="UndertowRealm">
>     <server-identities>
>         <ssl>
>             <keystore path="keystore.jks" relative-to="jboss.server.config.dir" keystore-password="mypassword" alias="server" key-password="mypassword"/>
>         </ssl>
>     </server-identities>
> </security-realm>
> <https-listener name="default-https" socket-binding="https" security-realm="UndertowRealm"/>
> If I type on the browser https://localhost/ca/user/1 everything is just fine, but if I type http://localhost/ca/user/1, instead of redirecting to http://localhost/ca/user/1 I get the following error:
> 2015-06-03 01:49:28,228 ERROR [io.undertow.request] (default task-1) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:80)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> 	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(ThreadPoolExecutor.java:1110)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 	at java.lang.Thread.run(Thread.java:722)
> Please note that this issue doesn't happen over WildFly 8.2 Final



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4206)
 jboss-javaee-7.0-with-resteasy bom exposes JUnit as dependency
In-Reply-To: <JIRA.12560123.1419938753000@Atlassian.JIRA>
References: <JIRA.12560123.1419938753000@Atlassian.JIRA>
	<JIRA.12560123.1419938753000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560123.1419938753000.89782.1512580815492@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4206:
-----------------------------
    Fix Version/s: 9.0.0.Final


> jboss-javaee-7.0-with-resteasy bom exposes JUnit as dependency
> --------------------------------------------------------------
>
>                 Key: WFLY-4206
>                 URL: https://issues.jboss.org/browse/WFLY-4206
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 8.2.0.Final
>            Reporter: James Bodkin
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> The jboss-javaee-7.0-with-resteasy bom includes the JUnit dependency, I believe this should be included with the jboss-javaee-7.0-with-tools bom instead. (It seems to already be included in tools as well)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4134) Java EE 7 Quickstarts
In-Reply-To: <JIRA.12558336.1417107520000@Atlassian.JIRA>
References: <JIRA.12558336.1417107520000@Atlassian.JIRA>
	<JIRA.12558336.1417107520000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558336.1417107520000.89785.1512580815579@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4134:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Java EE 7 Quickstarts
> ---------------------
>
>                 Key: WFLY-4134
>                 URL: https://issues.jboss.org/browse/WFLY-4134
>             Project: WildFly
>          Issue Type: Task
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 9.0.0.Final
>
>
> WildFly Quickstarts should demo the technologies introduced/updated by Java EE 7.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used
In-Reply-To: <JIRA.12546940.1405933728000@Atlassian.JIRA>
References: <JIRA.12546940.1405933728000@Atlassian.JIRA>
	<JIRA.12546940.1405933728000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546940.1405933728000.89794.1512580815810@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3651:
-----------------------------
    Fix Version/s: 9.0.0.Final


> permissions.xml is not used
> ---------------------------
>
>                 Key: WFLY-3651
>                 URL: https://issues.jboss.org/browse/WFLY-3651
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security Manager
>    Affects Versions: 8.1.0.Final
>         Environment: Fedora 20, jdk1.7.0_60
>            Reporter: Ondrej Kotek
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 9.0.0.Final
>
>         Attachments: wfly3651.war
>
>
> With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2839) Remote Naming communication
 exception should be thrown on ConnectException
In-Reply-To: <JIRA.12530687.1391029853000@Atlassian.JIRA>
References: <JIRA.12530687.1391029853000@Atlassian.JIRA>
	<JIRA.12530687.1391029853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530687.1391029853000.89798.1512580815965@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2839:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Remote Naming communication exception should be thrown on ConnectException
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2839
>                 URL: https://issues.jboss.org/browse/WFLY-2839
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>             Fix For: 9.0.0.Final
>
>
> Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException.  This is related to WFLY-2198



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4606) Operation
 read-resource-description invoked against multiple target addresses failed
In-Reply-To: <JIRA.12570990.1430998167000@Atlassian.JIRA>
References: <JIRA.12570990.1430998167000@Atlassian.JIRA>
	<JIRA.12570990.1430998167000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570990.1430998167000.89802.1512580816033@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4606:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Operation read-resource-description invoked against multiple target addresses failed 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-4606
>                 URL: https://issues.jboss.org/browse/WFLY-4606
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 9.0.0.CR1
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 9.0.0.Final
>
>
> {noformat}
> [domain at localhost:9990 /] /profile=full/subsystem=undertow/servlet-container=*/setting=websocket:read-resource-description
> {
>     "outcome" => "failed",
>     "result" => [{
>         "address" => [
>             ("profile" => "full"),
>             ("subsystem" => "undertow"),
>             ("servlet-container" => "*"),
>             ("setting" => "websocket")
>         ],
>         "outcome" => "failed",
>         "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>         "rolled-back" => true
>     }],
>     "failure-description" => "WFLYCTL0285: Operation read-resource-description invoked against multiple target addresses failed at address [
>     (\"profile\" => \"full\"),
>     (\"subsystem\" => \"undertow\"),
>     (\"servlet-container\" => \"*\"),
>     (\"setting\" => \"websocket\")
> ] with failure description WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
>     "rolled-back" => true
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2849) Upgrade jboss-remote-naming
 to 2.0.0 Final or later
In-Reply-To: <JIRA.12530807.1391112160000@Atlassian.JIRA>
References: <JIRA.12530807.1391112160000@Atlassian.JIRA>
	<JIRA.12530807.1391112160000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530807.1391112160000.89807.1512580816165@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2849:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Upgrade jboss-remote-naming to 2.0.0 Final or later
> ---------------------------------------------------
>
>                 Key: WFLY-2849
>                 URL: https://issues.jboss.org/browse/WFLY-2849
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Eduardo Martins
>             Fix For: 9.0.0.Final
>
>
> Upgrade jboss-remote-naming to 2.0.0 Final or later to resolve linked issues



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4121) Wrong LDAP host used in
 AdvancedLdapLoginModuleTestCase
In-Reply-To: <JIRA.12558104.1416906133000@Atlassian.JIRA>
References: <JIRA.12558104.1416906133000@Atlassian.JIRA>
	<JIRA.12558104.1416906133000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558104.1416906133000.89811.1512580816371@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4121:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Wrong LDAP host used in AdvancedLdapLoginModuleTestCase
> -------------------------------------------------------
>
>                 Key: WFLY-4121
>                 URL: https://issues.jboss.org/browse/WFLY-4121
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> An update in {{NetworkUtils.formatPossibleIpv6Address(address)}} method canonizes IPv6 addresses now. The {{AdvancedLdapLoginModuleTestCase}} has to be updated to use correct format for LDAP server SPN in KDC.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4233) Kitchensink Quickstarts have
 missing links on README.md
In-Reply-To: <JIRA.12560548.1420741457000@Atlassian.JIRA>
References: <JIRA.12560548.1420741457000@Atlassian.JIRA>
	<JIRA.12560548.1420741457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560548.1420741457000.89814.1512580816417@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4233:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Kitchensink Quickstarts have missing links on README.md
> -------------------------------------------------------
>
>                 Key: WFLY-4233
>                 URL: https://issues.jboss.org/browse/WFLY-4233
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rafael Benevides
>            Assignee: Rafael Benevides
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1502) Installing the HAL console as
 a layer doesn't work
In-Reply-To: <JIRA.12494074.1371020117000@Atlassian.JIRA>
References: <JIRA.12494074.1371020117000@Atlassian.JIRA>
	<JIRA.12494074.1371020117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494074.1371020117000.89819.1512580816556@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1502:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Installing the HAL console as a layer doesn't work
> --------------------------------------------------
>
>                 Key: WFLY-1502
>                 URL: https://issues.jboss.org/browse/WFLY-1502
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>             Fix For: 9.0.0.Final
>
>
> The installation procedure for layered products [1] doesn't work. The updated console ins't pulled in.
> [1] https://github.com/hal/release-stream/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3747) build.bat can not run without
 the administrator on the windows
In-Reply-To: <JIRA.12549697.1408516725000@Atlassian.JIRA>
References: <JIRA.12549697.1408516725000@Atlassian.JIRA>
	<JIRA.12549697.1408516725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549697.1408516725000.89822.1512580816669@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3747:
-----------------------------
    Fix Version/s: 9.0.0.Final


> build.bat can not run without the administrator on the windows
> --------------------------------------------------------------
>
>                 Key: WFLY-3747
>                 URL: https://issues.jboss.org/browse/WFLY-3747
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 9.0.0.Final
>
>         Attachments: 0001-Update-to-bypass-the-execution-policy-on-the-windows.patch
>
>
> we are building the widlfy on the windows and meet the following failure. It looks like the powershell needs the Administrator to run the script.
> {noformat}
> C:\hudson\workspace\btny-pulls-narayana-windows2008\jboss-as\tools\download-maven.ps1
> cannot be loaded because the execution of scripts is disabled on this
> system. Please see "get-help about_signing" for more details.
> At line:1 char:2
> + & <<<<  tools\download-maven.ps1
>     + CategoryInfo          : NotSpecified: (:) [],
> PSSecurityException
>     + FullyQualifiedErrorId : RuntimeException
> {noformat}
> It could be set the execution policy or bypass it. see http://stackoverflow.com/questions/4037939/powershell-execution-of-scripts-is-disabled-on-this-system



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4293) deprecate :enable :disable
 operation for (xa)DataSource
In-Reply-To: <JIRA.12561957.1422518896000@Atlassian.JIRA>
References: <JIRA.12561957.1422518896000@Atlassian.JIRA>
	<JIRA.12561957.1422518896000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561957.1422518896000.89826.1512580816778@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4293:
-----------------------------
    Fix Version/s: 9.0.0.Final


> deprecate :enable :disable operation for (xa)DataSource
> -------------------------------------------------------
>
>                 Key: WFLY-4293
>                 URL: https://issues.jboss.org/browse/WFLY-4293
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>
> Those operations will no more supported in next version of WF. They will stau in MODEL stage to permit domain administration on older version server, but RUNTIME stage will be removed and operation will fail.
> Also enabled attribute will be updated to maintain consistent behavior 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3763) move as many as possible of
 the cli tests from wildfly to wildfly-core
In-Reply-To: <JIRA.12550070.1408722833000@Atlassian.JIRA>
References: <JIRA.12550070.1408722833000@Atlassian.JIRA>
	<JIRA.12550070.1408722833000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12550070.1408722833000.89830.1512580816986@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3763:
-----------------------------
    Fix Version/s: 9.0.0.Final


> move as many as possible of the cli tests from wildfly to wildfly-core
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3763
>                 URL: https://issues.jboss.org/browse/WFLY-3763
>             Project: WildFly
>          Issue Type: Task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 9.0.0.Final
>
>
> The CLI testsuite really belongs next to the CLI sourcecode. Except those tests that require functionality not available in the core, e.g. data-source related commands, etc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1716) NoClassDefFoundError:
 org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
In-Reply-To: <JIRA.12496755.1374137088000@Atlassian.JIRA>
References: <JIRA.12496755.1374137088000@Atlassian.JIRA>
	<JIRA.12496755.1374137088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496755.1374137088000.89836.1512580817166@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1716:
-----------------------------
    Fix Version/s: 9.0.0.Final


> NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-1716
>                 URL: https://issues.jboss.org/browse/WFLY-1716
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Alpha3
>         Environment: Win 7, JEE 6, JDK 7
>            Reporter: Oliver Pfau
>            Assignee: Stuart Douglas
>              Labels: Deploy, classnotfound, war
>             Fix For: 9.0.0.Final
>
>
> I tried to deploy my ear which works in JBoss 7 in wildfly and got the following error on deploy:
> 09:59:55,060 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "mywar.war" of deployment "my.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	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: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
> 	at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> 	... 5 more
> 09:59:55,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "my.ear")]) - failure description: {
>     "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"mywar.war\" of deployment \"my.ear\"
>     Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache"},
>     "JBAS014771: Services with missing/unavailable dependencies" => [
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.ValidatorFactory is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.InstanceName is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.Validator is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         
> 		<all other services>
>     ]
> }



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3716) Upgrade JAXB to 2.2.5.jboss-2
 for bug fixes
In-Reply-To: <JIRA.12548766.1407356756000@Atlassian.JIRA>
References: <JIRA.12548766.1407356756000@Atlassian.JIRA>
	<JIRA.12548766.1407356756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12548766.1407356756000.89841.1512580817331@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3716:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Upgrade JAXB to 2.2.5.jboss-2 for bug fixes
> -------------------------------------------
>
>                 Key: WFLY-3716
>                 URL: https://issues.jboss.org/browse/WFLY-3716
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: XML Frameworks
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: 9.0.0.Final
>
>
> Upgrade jaxb to 2.2.5.jboss-2 to include some bug fixes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1680) Upgrade batch integration to
 use jberet-core 1.0.0.Alpha2
In-Reply-To: <JIRA.12496239.1373581244000@Atlassian.JIRA>
References: <JIRA.12496239.1373581244000@Atlassian.JIRA>
	<JIRA.12496239.1373581244000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496239.1373581244000.89845.1512580817440@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1680:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Upgrade batch integration to use jberet-core 1.0.0.Alpha2
> ---------------------------------------------------------
>
>                 Key: WFLY-1680
>                 URL: https://issues.jboss.org/browse/WFLY-1680
>             Project: WildFly
>          Issue Type: Task
>          Components: EE
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Cheng Fang
>            Assignee: Cheng Fang
>             Fix For: 9.0.0.Final
>
>
> Need to upgrade to jberet 1.0.0.Alpha2 (to be released soon) to fix class loading problems in modular environment and improve object cloning with jboss marshalling.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4140) In some case :activare on
 resource-adapter fails if id != archive_name
In-Reply-To: <JIRA.12558375.1417181785000@Atlassian.JIRA>
References: <JIRA.12558375.1417181785000@Atlassian.JIRA>
	<JIRA.12558375.1417181785000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558375.1417181785000.89850.1512580817545@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4140:
-----------------------------
    Fix Version/s: 9.0.0.Final


> In some case :activare on resource-adapter fails if id != archive_name
> ----------------------------------------------------------------------
>
>                 Key: WFLY-4140
>                 URL: https://issues.jboss.org/browse/WFLY-4140
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>
> deploy /home/jolee/amq.rar
> /subsystem=resource-adapters/resource-adapter=amq:add(archive=amq.rar,transaction-support=XATransaction)
> /subsystem=resource-adapters/resource-adapter=amq/config-properties=UseInboundSession:add(value=false)
> /subsystem=resource-adapters/resource-adapter=amq/config-properties=ServerUrl:add(value="vm://localhost")
> /subsystem=resource-adapters/resource-adapter=amq/config-properties=BrokerXmlConfig:add(value="xbean:broker-config.xml")
> /subsystem=resource-adapters/resource-adapter=amq/connection-definitions=ConnectionFactory:add(jndi-name=java:jboss/ConnectionFactory,use-java-context=true,class-name=org.apache.activemq.ra.ActiveMQManagedConnectionFactory,enabled=true)
> /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAIProcessStarter:add(jndi-name=java:jboss/queue/EAIProcessStarter,use-java-context=false,class-name=org.apache.activemq.command.ActiveMQQueue,enabled=true)
> /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAIProcessStarter/config-properties=PhysicalName:add(value=EAIProcessStarter)
> /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAI_TRIGGER:add(jndi-name=java:/jboss/queue/EAI_TRIGGER,use-java-context=true,class-name=org.apache.activemq.command.ActiveMQQueue,enabled=true)
> /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAI_TRIGGER/config-properties=PhysicalName:add(value=EAI_TRIGGER)
> /subsystem=resource-adapters/resource-adapter=amq:activate
> [4]
> [standalone at localhost:9999 /] run-batch --file=/home/jolee/rar2.cli
> {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-10" => "JBAS010480: RAR 'amq' not yet deployed."}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3645) Upgrade JBoss Marshalling to
	1.4.8.Final
In-Reply-To: <JIRA.12546876.1405709566000@Atlassian.JIRA>
References: <JIRA.12546876.1405709566000@Atlassian.JIRA>
	<JIRA.12546876.1405709566000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546876.1405709566000.89857.1512580817751@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3645:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Upgrade JBoss Marshalling to 1.4.8.Final
> ----------------------------------------
>
>                 Key: WFLY-3645
>                 URL: https://issues.jboss.org/browse/WFLY-3645
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final, 8.2.0.Final
>            Reporter: Ariel K?chler
>            Assignee: David Lloyd
>            Priority: Critical
>              Labels: marshalling, session
>             Fix For: 9.0.0.Final
>
>
> Please upgrade JBoss Marshalling to 1.4.8.Final to fix the bug JBMAR-163.
> This fix repair the session restore after a Wildfly restart.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:20:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1616) Release core console 1.5.4
 (HAL Dependency)
In-Reply-To: <JIRA.12495398.1372664643000@Atlassian.JIRA>
References: <JIRA.12495398.1372664643000@Atlassian.JIRA>
	<JIRA.12495398.1372664643000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495398.1372664643000.89861.1512580817828@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1616:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Release core console 1.5.4 (HAL Dependency)
> -------------------------------------------
>
>                 Key: WFLY-1616
>                 URL: https://issues.jboss.org/browse/WFLY-1616
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>             Fix For: 9.0.0.Final
>
>
> As a dependency for HAL extensions



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1065) Update JBoss Transactions to
	5.0.0.M3
In-Reply-To: <JIRA.12487705.1363872076000@Atlassian.JIRA>
References: <JIRA.12487705.1363872076000@Atlassian.JIRA>
	<JIRA.12487705.1363872076000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487705.1363872076000.89866.1512580818039@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1065:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Update JBoss Transactions to 5.0.0.M3
> -------------------------------------
>
>                 Key: WFLY-1065
>                 URL: https://issues.jboss.org/browse/WFLY-1065
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1750) Low level permissions for the
 useware kernel
In-Reply-To: <JIRA.12497209.1374646022000@Atlassian.JIRA>
References: <JIRA.12497209.1374646022000@Atlassian.JIRA>
	<JIRA.12497209.1374646022000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497209.1374646022000.89869.1512580818094@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1750:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Low level permissions for the useware kernel 
> ---------------------------------------------
>
>                 Key: WFLY-1750
>                 URL: https://issues.jboss.org/browse/WFLY-1750
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1240) Review Coverity reports for
 JBossWS integration
In-Reply-To: <JIRA.12481625.1356000235000@Atlassian.JIRA>
References: <JIRA.12481625.1356000235000@Atlassian.JIRA>
	<JIRA.12481625.1356000235000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481625.1356000235000.89874.1512580818311@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1240:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Review Coverity reports for JBossWS integration
> -----------------------------------------------
>
>                 Key: WFLY-1240
>                 URL: https://issues.jboss.org/browse/WFLY-1240
>             Project: WildFly
>          Issue Type: Task
>          Components: Web Services
>            Reporter: Rostislav Svoboda
>            Assignee: Jim Ma
>             Fix For: 9.0.0.Final
>
>
> Please check reported items for WS integration in http://station5.brq.redhat.com:8080/reports.htm#v10037/p10007 - use prepared 'x WS issues' filter



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2156) Upgrade scannotation to 1.0.3
In-Reply-To: <JIRA.12501531.1380123304000@Atlassian.JIRA>
References: <JIRA.12501531.1380123304000@Atlassian.JIRA>
	<JIRA.12501531.1380123304000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501531.1380123304000.89880.1512580818425@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2156:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Upgrade scannotation to 1.0.3
> -----------------------------
>
>                 Key: WFLY-2156
>                 URL: https://issues.jboss.org/browse/WFLY-2156
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Weinan Li
>            Assignee: Weinan Li
>             Fix For: 9.0.0.Final
>
>
> RESTEasy has a dependency on 1.0.3 of scannotation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1394) Add resteasy-crypto to WildFly
In-Reply-To: <JIRA.12492645.1369378058000@Atlassian.JIRA>
References: <JIRA.12492645.1369378058000@Atlassian.JIRA>
	<JIRA.12492645.1369378058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492645.1369378058000.89886.1512580818619@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1394:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Add resteasy-crypto to WildFly
> ------------------------------
>
>                 Key: WFLY-1394
>                 URL: https://issues.jboss.org/browse/WFLY-1394
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Weinan Li
>            Assignee: Stuart Douglas
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> Customers want to use resteasy-crypto inside WildFly. We may need to add this module in future releases.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3162) audit syslog handler should
 be able to automatically reconnect
In-Reply-To: <JIRA.12536088.1395787531000@Atlassian.JIRA>
References: <JIRA.12536088.1395787531000@Atlassian.JIRA>
	<JIRA.12536088.1395787531000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536088.1395787531000.89891.1512580818748@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3162:
-----------------------------
    Fix Version/s: 9.0.0.Final


> audit syslog handler should be able to automatically reconnect
> --------------------------------------------------------------
>
>                 Key: WFLY-3162
>                 URL: https://issues.jboss.org/browse/WFLY-3162
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Kabir Khan
>              Labels: EAP
>             Fix For: 9.0.0.Final
>
>
> When the syslog server goes down, WF will retry (up to 10 times we believe) to reconnect but will then give up. You can manually force a reconnect by issuing:
> /host=master/core-service=management/access=audit/syslog-handler=mysyslog:recycle
> This request is to make it possible to automate this and make it configurable at which interval it should try and reconnect



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1671)
 org.apache.commons.configuration missing dependency on
 org.apache.commons.beanutils
In-Reply-To: <JIRA.12496156.1373501865000@Atlassian.JIRA>
References: <JIRA.12496156.1373501865000@Atlassian.JIRA>
	<JIRA.12496156.1373501865000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496156.1373501865000.89897.1512580818857@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1671:
-----------------------------
    Fix Version/s: 9.0.0.Final


> org.apache.commons.configuration missing dependency on org.apache.commons.beanutils
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1671
>                 URL: https://issues.jboss.org/browse/WFLY-1671
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: James Livingston
>            Assignee: Paul Gier
>             Fix For: 9.0.0.Final
>
>
> Apache commons configuration uses commons bean-utils in a few places, but the module.xml does not declare a dependency on it.
> The POM (http://search.maven.org/#artifactdetails|commons-configuration|commons-configuration|1.6|jar) also suggests that digesters is also a dependency, but I haven't seen any issues from that being missing.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4201) Outdated Quickstarts
 Openshift instructions
In-Reply-To: <JIRA.12560019.1419337324000@Atlassian.JIRA>
References: <JIRA.12560019.1419337324000@Atlassian.JIRA>
	<JIRA.12560019.1419337324000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560019.1419337324000.89900.1512580818919@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4201:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Outdated Quickstarts Openshift instructions 
> --------------------------------------------
>
>                 Key: WFLY-4201
>                 URL: https://issues.jboss.org/browse/WFLY-4201
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 9.0.0.Final
>
>
> Quickstarts which may be deployed at Openshift have related documentation outdated.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1093) Group assignment doesnt
	refresh
In-Reply-To: <JIRA.12481140.1355484743000@Atlassian.JIRA>
References: <JIRA.12481140.1355484743000@Atlassian.JIRA>
	<JIRA.12481140.1355484743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481140.1355484743000.89904.1512580819003@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1093:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Group assignment doesnt refresh
> -------------------------------
>
>                 Key: WFLY-1093
>                 URL: https://issues.jboss.org/browse/WFLY-1093
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3635) Quickstart TOC not appearing
 in Readme.md. Page generally broken.
In-Reply-To: <JIRA.12546652.1405523322000@Atlassian.JIRA>
References: <JIRA.12546652.1405523322000@Atlassian.JIRA>
	<JIRA.12546652.1405523322000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546652.1405523322000.89909.1512580819147@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3635:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Quickstart TOC not appearing in Readme.md. Page generally broken.
> -----------------------------------------------------------------
>
>                 Key: WFLY-3635
>                 URL: https://issues.jboss.org/browse/WFLY-3635
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation
>            Reporter: Sarah Weissman
>            Assignee: Tomaz Cerar
>             Fix For: 9.0.0.Final
>
>
> All the getting started documentation points to the Github Readme.md page, which is pretty broken. Instead of a list of quickstarts there is just dead text saying "[TOC Quickstart]"
> https://github.com/wildfly/quickstart
> "Quickstarts with tutorials in the Get Started Developing Applications are noted with two asterisks ( ** ) following the quickstart name.
> [TOC-quickstart]"
> Additionally the "Get Started Developing Applications" link is broken.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2974) jboss.home.dir and
 jbossas.ts.dir properties are not propagated to Policy File in Domain
 testsuite
In-Reply-To: <JIRA.12532755.1392877012000@Atlassian.JIRA>
References: <JIRA.12532755.1392877012000@Atlassian.JIRA>
	<JIRA.12532755.1392877012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532755.1392877012000.89912.1512580819270@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2974:
-----------------------------
    Fix Version/s: 9.0.0.Final


> jboss.home.dir and jbossas.ts.dir properties are not propagated to Policy File in Domain testsuite
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2974
>                 URL: https://issues.jboss.org/browse/WFLY-2974
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Lukas
>             Fix For: 9.0.0.Final
>
>
> Testsuite Policy File using jbossas.ts.dir and jboss.home.dir properties, but they are not set for servers and controllers jvm in domain testsuite running with Security Manager.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3405) Variable interpolation not
 applied to remote-outbound-connection username attribute due to calling
 asString() instead of resolve() on the ModelValue
In-Reply-To: <JIRA.12541950.1401184234000@Atlassian.JIRA>
References: <JIRA.12541950.1401184234000@Atlassian.JIRA>
	<JIRA.12541950.1401184234000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541950.1401184234000.89917.1512580819384@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3405:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Variable interpolation not applied to remote-outbound-connection username attribute due to calling asString() instead of resolve() on the ModelValue
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3405
>                 URL: https://issues.jboss.org/browse/WFLY-3405
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting
>    Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final, 8.1.0.Final
>            Reporter: Mikal Henriksen
>            Assignee: Enrique Gonz?lez Mart?nez
>             Fix For: 9.0.0.Final
>
>
> We want to externalize the username and password used for remote ejb between two AS7.2 instances. But variable interpolation does not work in the <remote-outbound-connection> element's username attribute. It always sends the variable expression verbatim according to attached debugger, and trace logging of org.jboss.security on the target server.
> I dug through the code and found the problem. The offending line as of writing this:
> https://github.com/wildfly/wildfly/blob/dd3724f600e00e9cc539066cf0bd359f73d62064/remoting/subsystem/src/main/java/org/jboss/as/remoting/RemoteOutboundConnectionAdd.java#L80
> I checked the api here: http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss/jboss-dmr/1.2.0.Final/org/jboss/dmr/ExpressionValue.java#ExpressionValue.asString%28%29
> It looks like you're supposed to use resolve(), not asString(). The earliest version I verified this mistake was 7.2.0.Final, which is the version we're running. It's still there in the latest revision of master of the Wildfly repo.
> This problem possibly also affects other elements and attributes, so you may want to do a full usage scan of org.jboss.dmr.ModelValue#asString().



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:20:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4322) Update JSF based on Mojarra
	2.2.10
In-Reply-To: <JIRA.12562530.1423159434000@Atlassian.JIRA>
References: <JIRA.12562530.1423159434000@Atlassian.JIRA>
	<JIRA.12562530.1423159434000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562530.1423159434000.89922.1512580819511@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4322:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Update JSF based on Mojarra 2.2.10
> ----------------------------------
>
>                 Key: WFLY-4322
>                 URL: https://issues.jboss.org/browse/WFLY-4322
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JSF
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: 9.0.0.Final
>
>
> Update JSF since Mojarra 2.2.10 was just released.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1776) resource-adapter id attribute
 is forced to match rar name
In-Reply-To: <JIRA.12497520.1375113090000@Atlassian.JIRA>
References: <JIRA.12497520.1375113090000@Atlassian.JIRA>
	<JIRA.12497520.1375113090000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497520.1375113090000.89930.1512580819771@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1776:
-----------------------------
    Fix Version/s: 9.0.0.Final


> resource-adapter id attribute is forced to match rar name
> ---------------------------------------------------------
>
>                 Key: WFLY-1776
>                 URL: https://issues.jboss.org/browse/WFLY-1776
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Johnathon Lee
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>         Attachments: JBJCA-1066-reproducer.zip
>
>
> If the id of the resource adapter element does not match the name of the
> RAR file, the CLI will throw the following error on RA activation:
> {
>     "outcome" => "failed",
>     "failure-description" => "rar not yet deployed",
>     "rolled-back" => true
> }



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1518)
 HornetQBackupActivationTestCase runs into intermittent failures
In-Reply-To: <JIRA.12494181.1371127277000@Atlassian.JIRA>
References: <JIRA.12494181.1371127277000@Atlassian.JIRA>
	<JIRA.12494181.1371127277000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494181.1371127277000.89935.1512580819894@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1518:
-----------------------------
    Fix Version/s: 9.0.0.Final


> HornetQBackupActivationTestCase runs into intermittent failures
> ---------------------------------------------------------------
>
>                 Key: WFLY-1518
>                 URL: https://issues.jboss.org/browse/WFLY-1518
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Jeff Mesnil
>             Fix For: 9.0.0.Final
>
>         Attachments: log.txt
>
>
> The HornetQBackupActivationTestCase#testPassiveBackupReload() failed on TeamCity environment against latest upstream/master. I haven't yet had a detailed look at it. The exception stacktrace looks like:
> {code}
> Caused by: java.util.concurrent.ExecutionException: Operation failed
>     at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>     at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>     at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
>     at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
>     ... 93 more
> Caused by: java.io.IOException: Channel closed
>     at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:381)
>     at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:137)
>     at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:134)
>     at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
>     at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:531)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
>     at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:399)
>     at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:108)
>     at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
>     at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
>     at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
>     at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:195)
>     at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:109)
>     at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
>     at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052)
>     at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
>     at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61)
>     at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85)
>     at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> {code}
> There's also some complaints about connection leaks in those logs:
> {code}
> 13:17:26,866 WARN  [org.jboss.as.controller.client] (Finalizer) JBAS010600: Closing leaked controller client: JBAS010649: Allocation stack trace:
>     at java.lang.Thread.getStackTrace(Thread.java:1567)
>     at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:76)
>     at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:337)
>     at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:147)
>     at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.createBackupClient(HornetQBackupActivationTestCase.java:107)
>     at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.waitForBackupServerToReload(HornetQBackupActivationTestCase.java:297)
>     at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.testActiveBackupReload(HornetQBackupActivationTestCase.java:224)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> The entire log has been attached to the JIRA.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3241) KDC server does not bind to
 correct address
In-Reply-To: <JIRA.12537797.1397122893000@Atlassian.JIRA>
References: <JIRA.12537797.1397122893000@Atlassian.JIRA>
	<JIRA.12537797.1397122893000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12537797.1397122893000.89939.1512580819968@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3241:
-----------------------------
    Fix Version/s: 9.0.0.Final


> KDC server does not bind to correct address
> -------------------------------------------
>
>                 Key: WFLY-3241
>                 URL: https://issues.jboss.org/browse/WFLY-3241
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.1.0.CR1
>            Reporter: Dominik Pospisil
>            Assignee: Dominik Pospisil
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2706) ServletContext.getServerInfo:
 Undertow instead of JBoss or Wildfly
In-Reply-To: <JIRA.12528576.1388740415000@Atlassian.JIRA>
References: <JIRA.12528576.1388740415000@Atlassian.JIRA>
	<JIRA.12528576.1388740415000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528576.1388740415000.89945.1512580820157@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2706:
-----------------------------
    Fix Version/s: 9.0.0.Final


> ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
> ------------------------------------------------------------------
>
>                 Key: WFLY-2706
>                 URL: https://issues.jboss.org/browse/WFLY-2706
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOS, OpenJDK7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.Final
>
>
> javax.servlet.ServletContext.getServerInfo() identifies Wildfly with:
> "Undertow" and not with JBoss or Wildfly. Is this intentional?
> Some frameworks or extensions (e.g. JavaMelody) use this server info to provide application server specific behaviour.
> So Wildfly (or the newer JBoss AS) is quite different to past versions and this must not be the wrong step to tell something different here, but providing the embedded Servlet Container "Undertow" as response might not be intentional?
> I would suggest to show something with "JBoss" even though Wildfly is the community version name (BTW great move...who wants to have wild flies in his data center...where is our swatter)
> JavaMelody example code, triggered by HttpSessionListener.contextInitialized(ServletContextEvent event) -> initServletContext(event.getServletContext()):
> void initServletContext(ServletContext context) {
> 		assert context != null;
> 		this.servletContext = context;
> 		final String serverInfo = servletContext.getServerInfo();
> 		jboss = serverInfo.contains("JBoss") ;
> 		glassfish = serverInfo.contains("GlassFish")
> 				|| serverInfo.contains("Sun Java System Application Server");
> 		weblogic = serverInfo.contains("WebLogic");
> 		jonas = System.getProperty("jonas.name") != null;



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3166) can't enable datasource both
 via console or CLI with cluster mode(can't persist to domain.xml)
In-Reply-To: <JIRA.12536115.1395823814000@Atlassian.JIRA>
References: <JIRA.12536115.1395823814000@Atlassian.JIRA>
	<JIRA.12536115.1395823814000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536115.1395823814000.89956.1512580820426@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3166:
-----------------------------
    Fix Version/s: 9.0.0.Final


> can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3166
>                 URL: https://issues.jboss.org/browse/WFLY-3166
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA, Web Console
>    Affects Versions: 8.0.0.Final
>         Environment: Red Hat Enterprise Linux Server release 5.5
>            Reporter: Fai Gao
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>
> Create a MySQL datasource via CLI:
> /profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)
> And then enable it via console,but the lable of enabled didn't turn to ?(enabled).
> Check the domain.xml,the value of enabled is still false.
> Enable it again whether via CLI or console,error log print:
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
>     "rolled-back" => true,
>     "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
>         "outcome" => "failed",
>         "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
>         "rolled-back" => true
>     }}}}}}
> }
> [Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
> [Server:fserver1]     ("subsystem" => "datasources"),
> [Server:fserver1]     ("data-source" => "testmysql")
> [Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
> [Server:fserver1] 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> [Server:fserver1] 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:fserver1] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [Server:fserver1]
> I tried in the standalone mode,it worked.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:20:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1621) JPA view in management
 console is getting "No resource definition is registered for address..."
In-Reply-To: <JIRA.12495450.1372697790000@Atlassian.JIRA>
References: <JIRA.12495450.1372697790000@Atlassian.JIRA>
	<JIRA.12495450.1372697790000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495450.1372697790000.89960.1512580820503@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1621:
-----------------------------
    Fix Version/s: 9.0.0.Final


> JPA view in management console is getting "No resource definition is registered for address..."
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1621
>                 URL: https://issues.jboss.org/browse/WFLY-1621
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Scott Marlow
>            Assignee: Heiko Braun
>             Fix For: 9.0.0.Final
>
>
> Reported by ehsavoie on IRC:
> {quote}
> <ehsavoie> it looks like wildfly is looking for a  "hibernate-persistence-unit" element in the jpa subsystem which creates an error 500 on the jpa tab in the admin console with the standalone default configuration. Shouldn't there be a default working config there ?
> <smarlow> ehsavoie: sounds like a bug, which build of WildFly?
> <ehsavoie> master from this morning
> <ehsavoie> the 500 error: http://fpaste.org/22146/
> <ehsavoie> smarlow: commit b5367674f6b3efb778fee8baa2739ff8fda4b4a5
> <smarlow> ehsavoie: okay, another question, is this with a JPA application deployed?  
> <ehsavoie> nope, blank standalone from the build
> <smarlow> ehsavoie: I'll try to recreate after my (master) build finishes.  I usually have some JPA application deployed when I use the management console so I probably missed this
> <ehsavoie> smarlow: the error is 'logical' as there are no resource so the context.getFailureDescription().set(MESSAGES.noSuchResourceType(stepAddress)); is not surprising
> <smarlow> ehsavoie: thanks, i reproduced it
> * fharms has quit (Quit: This computer has gone to sleep)
> <ehsavoie> smarlow: you're welcome
> {quote}
>  Internal Server Error
> "JBAS014883: No resource definition is registered for address [
> (\"deployment\" => \"*\"),
> (\"subsystem\" => \"jpa\"),
> (\"hibernate-persistence-unit\" => \"*\")
> ]"
> https://gist.github.com/scottmarlow/5902551



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1489) Incorrect heap description in
 VM metrics view
In-Reply-To: <JIRA.12493929.1370859389000@Atlassian.JIRA>
References: <JIRA.12493929.1370859389000@Atlassian.JIRA>
	<JIRA.12493929.1370859389000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493929.1370859389000.89965.1512580820645@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1489:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Incorrect heap description in VM metrics view
> ---------------------------------------------
>
>                 Key: WFLY-1489
>                 URL: https://issues.jboss.org/browse/WFLY-1489
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Chao Wang
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4295) warn about _ds.xml deplyments
 are deprecated
In-Reply-To: <JIRA.12561959.1422519123000@Atlassian.JIRA>
References: <JIRA.12561959.1422519123000@Atlassian.JIRA>
	<JIRA.12561959.1422519123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561959.1422519123000.89973.1512580820834@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4295:
-----------------------------
    Fix Version/s: 9.0.0.Final


> warn about _ds.xml deplyments are deprecated
> --------------------------------------------
>
>                 Key: WFLY-4295
>                 URL: https://issues.jboss.org/browse/WFLY-4295
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>
> _ds.xml deployement will no more supported in next vesions of WF. log a warning during deployment to warn users about that.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2750) Missing break for
 CommonIronJacamarParser.java
In-Reply-To: <JIRA.12529241.1389629620000@Atlassian.JIRA>
References: <JIRA.12529241.1389629620000@Atlassian.JIRA>
	<JIRA.12529241.1389629620000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529241.1389629620000.89976.1512580820891@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2750:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Missing break for CommonIronJacamarParser.java
> ----------------------------------------------
>
>                 Key: WFLY-2750
>                 URL: https://issues.jboss.org/browse/WFLY-2750
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Rostislav Svoboda
>            Assignee: Rostislav Svoboda
>             Fix For: 9.0.0.Final
>
>
> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/subsystems/resourceadapters/CommonIronJacamarParser.java#L178
> unterminated case for SHARABLE:
> {code}
>    case USE_CCM: {
>                     USE_CCM.parseAndSetParameter(value, connectionDefinitionNode, reader);
>                     break;
>                 }
>                 case SHARABLE: {
>                     SHARABLE.parseAndSetParameter(value, connectionDefinitionNode, reader);
>                 }
>                 case ENLISTMENT: {
>                     ENLISTMENT.parseAndSetParameter(value, connectionDefinitionNode, reader);
>                     break;
>                 }
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4684) EE Subsystem doesn't check
 some value of params when creating Concurrency utilities resources
In-Reply-To: <JIRA.12572922.1432727834000@Atlassian.JIRA>
References: <JIRA.12572922.1432727834000@Atlassian.JIRA>
	<JIRA.12572922.1432727834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572922.1432727834000.89980.1512580820967@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4684:
-----------------------------
    Fix Version/s: 9.0.0.Final


> EE Subsystem doesn't check some value of params when creating Concurrency utilities resources
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4684
>                 URL: https://issues.jboss.org/browse/WFLY-4684
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Hynek ?v?bek
>            Assignee: Hynek ?v?bek
>            Priority: Trivial
>             Fix For: 9.0.0.Final
>
>
> EE Subsystem doesn't check some value of params when creating Concurrency utilities resources
> {code}
> [standalone at localhost:9990 /] /subsystem=ee/managed-executor-service=other:add(jndi-name=java\:jboss\/ee\/executor\/other, core-threads=2, keepalive-time=-20)
> {
>     "outcome" => "failed",
>     "failure-description" => {"WFLYCTL0080: Failed services" => {"jboss.concurrent.ee.executor.other" => "org.jboss.msc.service.StartException in service jboss.concurrent.ee.executor.other: Failed to start service
>     Caused by: java.lang.IllegalArgumentException"}},
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> [standalone at localhost:9990 /] /subsystem=ee/managed-executor-service=other:add(jndi-name=java\:jboss\/ee\/executor\/other, core-threads=2, hung-task-threshold=-10
> Resources will be created.
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:20:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3689) Ability to specify a resource
 adapter reference in jboss-ejb3.xml without the ear name
In-Reply-To: <JIRA.12547800.1406653358000@Atlassian.JIRA>
References: <JIRA.12547800.1406653358000@Atlassian.JIRA>
	<JIRA.12547800.1406653358000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547800.1406653358000.89983.1512580821025@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3689:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Ability to specify a resource adapter reference in jboss-ejb3.xml without the ear name
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-3689
>                 URL: https://issues.jboss.org/browse/WFLY-3689
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EJB, JCA
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> Resource adapters can be packaged inside an EAR file. With the current set up it is necessary to specify the EAR name when referencing it jboss-ejb3.xml file.
> Extension is needed that would allow to avoid adding the EAR name all together for the resource adapter.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1149) Naming lookup intermittently
 fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is
 not open.
In-Reply-To: <JIRA.12479370.1353071425000@Atlassian.JIRA>
References: <JIRA.12479370.1353071425000@Atlassian.JIRA>
	<JIRA.12479370.1353071425000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479370.1353071425000.89994.1512580821289@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1149:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open.
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1149
>                 URL: https://issues.jboss.org/browse/WFLY-1149
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming, Test Suite
>         Environment: IBM JDK 6 (build 20110203_074623)
> IBM JDK 7 (build 20120809_118929)
>            Reporter: Ivo Studensky
>            Assignee: Jason Greene
>             Fix For: 9.0.0.Final
>
>         Attachments: endpoint_is_not_open_2012-11-26.xml, failed_with_status_cancelled_2012-11-26.xml, test_output_with_trace_logging_in_EndpointCache.xml
>
>
> RemoteNamingTestCase intermittently fails when running on IBM JDK. According to logs the remoting channel had been closed before the endpoint tried to connect to it. Unfortunately, when I was trying to debug this issue the tests always nicely passed.
> test.log snippet:
> {noformat}
> 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" read-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.EPollSelectorImpl at 345642e1
> 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" write-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.EPollSelectorImpl at 1dc68cf2
> 13:16:31,121 DEBUG [org.jboss.naming.remote.client.InitialContextFactory] (main) jboss.naming.client.connect.options. has the following options {org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false}
> 13:16:31,191 ERROR [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-1) Channel end notification received, closing channel Channel ID d1f17196 (outbound) of Remoting connection fd3dcedc to /127.0.0.1:4447
> 13:16:31,204 DEBUG [org.jboss.naming.remote.client.HaRemoteNamingStore] (main) Failed to connect to server remote://127.0.0.1:4447: org.jboss.remoting3.NotOpenException: Endpoint is not open
> 	at org.jboss.remoting3.EndpointImpl.resourceUntick(EndpointImpl.java:182)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:261)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
> 	at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105)
> 	at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:179)
> 	at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:117)
> 	at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223)
> 	at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> 	at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:422)
> 	at org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase.testRemoteLookup(RemoteNamingTestCase.java:74)
> {noformat}
> server.log snippet:
> {noformat}
> 13:16:31,025 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "test.jar"
> 13:16:31,163 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-3) Channel Opened - Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866
> 13:16:31,176 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-4) Chosen version 0x01
> 13:16:31,189 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" read-1) Channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 closed.
> 13:16:31,193 INFO  [org.jboss.as.naming] (Remoting "thinkpax" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to null
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4189) Wildfly Quickstarts using
 Java EE 6 references instead of Java EE 7
In-Reply-To: <JIRA.12559866.1418925813000@Atlassian.JIRA>
References: <JIRA.12559866.1418925813000@Atlassian.JIRA>
	<JIRA.12559866.1418925813000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559866.1418925813000.89997.1512580821347@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4189:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Wildfly Quickstarts using Java EE 6 references instead of Java EE 7
> -------------------------------------------------------------------
>
>                 Key: WFLY-4189
>                 URL: https://issues.jboss.org/browse/WFLY-4189
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Rafael Benevides
>            Assignee: Rafael Benevides
>              Labels: quickstarts
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1751)
 org.jboss.as.test.integration.jaxrs.provider.CustomProvidersTestCase.testProvidersInTwoWars
 if not skipped would fail on HP UX due to locale dependency
In-Reply-To: <JIRA.12497219.1374652010000@Atlassian.JIRA>
References: <JIRA.12497219.1374652010000@Atlassian.JIRA>
	<JIRA.12497219.1374652010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497219.1374652010000.90000.1512580821400@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1751:
-----------------------------
    Fix Version/s: 9.0.0.Final


> org.jboss.as.test.integration.jaxrs.provider.CustomProvidersTestCase.testProvidersInTwoWars if not skipped would fail on HP UX due to locale dependency
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1751
>                 URL: https://issues.jboss.org/browse/WFLY-1751
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>         Environment: HP UX 11 v3
>            Reporter: Pavel Jelinek
>            Assignee: Pavel Jelinek
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> Running on HP UX the test fails with stacktrace:
> org.junit.ComparisonFailure: expected:<[$]> but was:<[USD]>
> 	at org.junit.Assert.assertEquals(Assert.java:115)
> 	at org.junit.Assert.assertEquals(Assert.java:144)
> 	at org.jboss.as.test.integration.jaxrs.provider.CustomProvidersTestCase.testProvidersInTwoWars(CustomProvidersTestCase.java:102)
> 	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 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 	at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> 	at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> 	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 org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> 	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1474) Create a HAL build compatible
 with EAP 6.1.x
In-Reply-To: <JIRA.12493835.1370613379000@Atlassian.JIRA>
References: <JIRA.12493835.1370613379000@Atlassian.JIRA>
	<JIRA.12493835.1370613379000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493835.1370613379000.90004.1512580821507@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1474:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Create a HAL build compatible with EAP 6.1.x
> --------------------------------------------
>
>                 Key: WFLY-1474
>                 URL: https://issues.jboss.org/browse/WFLY-1474
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4271) Wildfly BOM wrong dependencies
In-Reply-To: <JIRA.12561264.1421762695000@Atlassian.JIRA>
References: <JIRA.12561264.1421762695000@Atlassian.JIRA>
	<JIRA.12561264.1421762695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561264.1421762695000.90008.1512580821585@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4271:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Wildfly BOM wrong dependencies
> ------------------------------
>
>                 Key: WFLY-4271
>                 URL: https://issues.jboss.org/browse/WFLY-4271
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.2.0.Final
>         Environment: Wildfly 8.2.0.Final, BOM org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final
>            Reporter: Vsevolod Golovanov
>            Assignee: Tomaz Cerar
>             Fix For: 9.0.0.Final
>
>
> 1. The BOM {{org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final}} (indirectly) imports {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} that has the following dependencies:
> {code}
> <version.io.undertow>1.0.1.Final</version.io.undertow>
> ...
> <dependency>
> 	<groupId>io.undertow</groupId>
> 	<artifactId>undertow-servlet</artifactId>
> 	<version>${version.io.undertow}</version>
> </dependency>
> <dependency>
> 	<groupId>io.undertow</groupId>
> 	<artifactId>undertow-core</artifactId>
> 	<version>${version.io.undertow}</version>
> </dependency>
> {code}
> The version should be 1.1.0.Final. The wrong version ends up being the effective one in dependencyManagement, messes up debugging in Eclipse, and probably compiling in Eclipse.
> 2. {{org.wildfly.bom:jboss-bom-parent:8.2.1.Final}}:
> {code}
> <version.org.hibernate-jpamodelgen>4.3.5.Final</version.org.hibernate-jpamodelgen>
> {code}
> , which affects {{org.wildfly.bom:jboss-javaee-7.0-with-hibernate:8.2.1.Final}}:
> {code}
> <dependency>
> 	<groupId>org.hibernate</groupId>
> 	<artifactId>hibernate-jpamodelgen</artifactId>
> 	<version>${version.org.hibernate-jpamodelgen}</version>
> </dependency>
> {code}
> Hibernate 4.3.7.Final from SourceForge has jpamodelgen 4.3.7.Final supplied.
> 3. {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} specifies a managed version 3.0.0 for {{org.glassfish:javax.el}}. The actual version supplied with Wildfly 8.2.0.Final is javax.el-3.0.1-b05. Maybe {{resteasy-jaxrs-all}} shouldn't export this managed version at all?
> Hoping for a BOM 8.2.2.Final release, because our project POMs are complex enough without workarounds for such errors.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-856) Error "Null Path" during VFS
 get virtual file
In-Reply-To: <JIRA.12464459.1334807998000@Atlassian.JIRA>
References: <JIRA.12464459.1334807998000@Atlassian.JIRA>
	<JIRA.12464459.1334807998000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464459.1334807998000.90015.1512580821804@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-856:
----------------------------
    Fix Version/s: 9.0.0.Final


> Error "Null Path" during VFS get virtual file
> ---------------------------------------------
>
>                 Key: WFLY-856
>                 URL: https://issues.jboss.org/browse/WFLY-856
>             Project: WildFly
>          Issue Type: Bug
>          Components: VFS
>            Reporter: Zhang Lan
>            Assignee: David Lloyd
>              Labels: jboss
>             Fix For: 9.0.0.Final
>
>
> I have a jar file ,in which have "seam.properties" to load the seam components in it.
> I put the jar file as a module.
> But I got the following error when I start jboss.
> java.lang.IllegalArgumentException: Null path		
>         at org.jboss.vfs.VFS.getChild(VFS.java:187) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final]		
>         at org.jboss.vfs.VFS.getChild(VFS.java:173) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final]		
>         at org.jboss.vfs.VFS.getChild(VFS.java:154) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final]		
>         at org.jboss.seam.integration.jbossas.vfs.VFSScanner.getRoot(VFSScanner.java:36) [jboss-seam-int.jar:6.0.0.GA]
> VFS.java:187 is following source.
>    return getChild(uri.getPath());
> But in my case ,the uri pattern is create by org.jboss.modules.JarFileResourceLoader#getJarURI use the following method.
>    return new URI("jar", b.toString(), null);
> It is the [scheme:]scheme-specific-part[#fragment] pattern 's URI.it's path is null.
> So when I change the VFS.java:187 to the following ,my problem is ok.IT's a bug?
> public static VirtualFile getChild(URI uri) {
>     if(uri.getPath() != null){
>       return getChild(uri.getPath());
>     }else{
>       return getChild(uri.getSchemeSpecificPart());
>     }
> }



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4276) Remove
 ${version.arquillian.container} from Kitchensink Quickstarts
In-Reply-To: <JIRA.12561378.1421867972000@Atlassian.JIRA>
References: <JIRA.12561378.1421867972000@Atlassian.JIRA>
	<JIRA.12561378.1421867972000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561378.1421867972000.90018.1512580821859@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4276:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Remove ${version.arquillian.container} from Kitchensink Quickstarts
> -------------------------------------------------------------------
>
>                 Key: WFLY-4276
>                 URL: https://issues.jboss.org/browse/WFLY-4276
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Rafael Benevides
>            Assignee: Rafael Benevides
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3661)
 PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName
 arg
In-Reply-To: <JIRA.12547378.1406204103000@Atlassian.JIRA>
References: <JIRA.12547378.1406204103000@Atlassian.JIRA>
	<JIRA.12547378.1406204103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547378.1406204103000.90022.1512580821943@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3661:
-----------------------------
    Fix Version/s: 9.0.0.Final


> PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3661
>                 URL: https://issues.jboss.org/browse/WFLY-3661
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 8.0.0.Final
>            Reporter: Jess Holle
>            Assignee: Kabir Khan
>             Fix For: 9.0.0.Final
>
>
> According to the Javadoc on MBeanRegistration.preRegister(), one may register an MBean with a null ObjectName and let the MBean's preRegister() method compute the ObjectName.
> Unfortunately, org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegateForNewObject() violates this contract -- throwing an exception when the incoming ObjectName is null.
> This is a clear bug which breaks numerous JMX MBeans I've authored, which compute their own ObjectNames within preRegister().
> Ideally the result of preRegister would be used as an input to findDelegateForNewObject(), but unfortunately one of the inputs to preRegister() is the MBeanServer, which is, of course, what findDelegateForNewObject() is looking up.  Given this circularity, it would seem that findDelegateForNewObject() should simply return rootMBeanServer for null ObjectName inputs.  In any case it should not entirely fail to register such MBeans.
> Fortunately, I have a utility wrapper around MBean registration, so I've added the following hack immediately prior to actually registering the MBean to workaround this issue:
>       /* Hack to work around JBoss Wildfly bug (https://issues.jboss.org/browse/WFLY-3661).
>          This isn't really quite correct, of course, since this means preRegister() will get called twice,
>          but it appears to be about the best we can do.
>       */
>       if ( objectName == null )
>         if ( mbean instanceof MBeanRegistration )
>           if ( "org.jboss.as.jmx.PluggableMBeanServerImpl".equals( mbeanserver.getClass().getName() ) )
>             objectName = ((MBeanRegistration)mbean).preRegister( mbeanserver, objectName );
> where mbeanserver is obtained via ManagementFactory.getPlatformMBeanServer().



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1625) WebConsole: Ability to mock
 different roles
In-Reply-To: <JIRA.12495516.1372764731000@Atlassian.JIRA>
References: <JIRA.12495516.1372764731000@Atlassian.JIRA>
	<JIRA.12495516.1372764731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495516.1372764731000.90026.1512580822006@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1625:
-----------------------------
    Fix Version/s: 9.0.0.Final


> WebConsole: Ability to mock different roles
> -------------------------------------------
>
>                 Key: WFLY-1625
>                 URL: https://issues.jboss.org/browse/WFLY-1625
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3696) Security domain configuration
 doesn't allow empty or missing login-module-stack
In-Reply-To: <JIRA.12547997.1406793172000@Atlassian.JIRA>
References: <JIRA.12547997.1406793172000@Atlassian.JIRA>
	<JIRA.12547997.1406793172000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547997.1406793172000.90034.1512580822244@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3696:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Security domain configuration doesn't allow empty or missing login-module-stack
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-3696
>                 URL: https://issues.jboss.org/browse/WFLY-3696
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.1.0.Final
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>             Fix For: 9.0.0.Final
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=901075 description: 
> project_key: JBPAPP6
> Adding a security domain with JASPI authentication fails if there is no (or is empty) login-module-stack. It should be possible to add custom ServerAuthModule, which doesn't use JAAS login modules.
> {code:xml}
> <security-domain name="jmx-console" cache-type="default">
> 	<authentication-jaspi>
> 		<!-- FIXME: the not empty login-module-stack must be provided even it's not used -->
> 		<login-module-stack name="lm-stack">
> 			<login-module code="UsersRoles" flag="required"/>
> 		</login-module-stack>
> 		<auth-module code="org.jboss.example.CustomServerAuthModule" flag="required">
> 			<module-option name="option1" value="value1" />
> 		</auth-module>
> 	</authentication-jaspi>
> </security-domain>
> {code}
> It should be possible to remove here the login-module-stack element.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4112) Update Wildfly JDF Stacks
 (BOM) for 8.2.0.Final
In-Reply-To: <JIRA.12557926.1416583299000@Atlassian.JIRA>
References: <JIRA.12557926.1416583299000@Atlassian.JIRA>
	<JIRA.12557926.1416583299000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557926.1416583299000.90038.1512580822334@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4112:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Update Wildfly JDF Stacks (BOM) for 8.2.0.Final
> -----------------------------------------------
>
>                 Key: WFLY-4112
>                 URL: https://issues.jboss.org/browse/WFLY-4112
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.2.0.Final
>            Reporter: Cody Lerum
>            Assignee: Eduardo Martins
>             Fix For: 9.0.0.Final
>
>
> The JDF stacks haven't been updated for Wildfly 8.2.0.Final
> This creates an issue for users wishing to keep the provided impl versions in sync with their project for debugging purposes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1534) HAL Release Stream 1.5.4.Final
In-Reply-To: <JIRA.12494312.1371223272000@Atlassian.JIRA>
References: <JIRA.12494312.1371223272000@Atlassian.JIRA>
	<JIRA.12494312.1371223272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494312.1371223272000.90044.1512580822484@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1534:
-----------------------------
    Fix Version/s: 9.0.0.Final


> HAL Release Stream 1.5.4.Final
> ------------------------------
>
>                 Key: WFLY-1534
>                 URL: https://issues.jboss.org/browse/WFLY-1534
>             Project: WildFly
>          Issue Type: Task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1834) Missing dependency for JDBC
 adapters module
In-Reply-To: <JIRA.12498026.1375777565000@Atlassian.JIRA>
References: <JIRA.12498026.1375777565000@Atlassian.JIRA>
	<JIRA.12498026.1375777565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498026.1375777565000.90050.1512580822642@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1834:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Missing dependency for JDBC adapters module
> -------------------------------------------
>
>                 Key: WFLY-1834
>                 URL: https://issues.jboss.org/browse/WFLY-1834
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> The jdbcadapters module needs an explicit dependency on ironjacamar.impl in order to allow all shipped recovery plugins to operate.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1343) Undertow: Cannot read filter
 and error-handler resources
In-Reply-To: <JIRA.12491818.1368606489000@Atlassian.JIRA>
References: <JIRA.12491818.1368606489000@Atlassian.JIRA>
	<JIRA.12491818.1368606489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491818.1368606489000.90055.1512580822738@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1343:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Undertow: Cannot read filter and error-handler resources
> --------------------------------------------------------
>
>                 Key: WFLY-1343
>                 URL: https://issues.jboss.org/browse/WFLY-1343
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Heiko Braun
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.Final
>
>
> {noformat}
> [standalone at localhost:9999 /] /subsystem=undertow/configuration=filter:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"subsystem\" => \"undertow\"),
>     (\"configuration\" => \"filter\")
> ]' not found",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
> {noformat}
> [standalone at localhost:9999 /] /subsystem=undertow/configuration=error-handler:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"subsystem\" => \"undertow\"),
>     (\"configuration\" => \"error-handler\")
> ]' not found",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1470) Usage of finalize() needs
 extra guards due to a flaw in the language feature (mostly affects IBM)
In-Reply-To: <JIRA.12493807.1370596070000@Atlassian.JIRA>
References: <JIRA.12493807.1370596070000@Atlassian.JIRA>
	<JIRA.12493807.1370596070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493807.1370596070000.90062.1512580822881@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1470:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM)
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1470
>                 URL: https://issues.jboss.org/browse/WFLY-1470
>             Project: WildFly
>          Issue Type: Task
>            Reporter: Carlo de Wolf
>            Assignee: Jason Greene
>            Priority: Critical
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2773) ClientConfigurationImpl
 should not translate IP address to host name
In-Reply-To: <JIRA.12529691.1389963183000@Atlassian.JIRA>
References: <JIRA.12529691.1389963183000@Atlassian.JIRA>
	<JIRA.12529691.1389963183000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529691.1389963183000.90066.1512580822957@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2773:
-----------------------------
    Fix Version/s: 9.0.0.Final


> ClientConfigurationImpl should not translate IP address to host name
> --------------------------------------------------------------------
>
>                 Key: WFLY-2773
>                 URL: https://issues.jboss.org/browse/WFLY-2773
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 9.0.0.Final
>
>
> When creating a ModelControllerClient and passing in an IP address, ClientConfigurationImpl internally translates it to a host name, like here:
> {noformat}
> public static ModelControllerClientConfiguration create(final InetAddress address, final int port) {
>         return new ClientConfigurationImpl(address.getHostName(), port, null, null, null, createDefaultExecutor(), true, null);
>     }
> {noformat}
> Later on, when the client connects, it is translated via DNS back to an IP address. This is not only unnecessary, but in some situations, it is wrong.
> Consider a Windows machine having two IP addresses ,A and B, on one network interface, where only A is pointed at by a DNS record. 
> - Run AS testsuite and pass it the address B as the node0 property, AS will bind itself to this address.
> - Now when a test creates a ModelControllerClient using IP address B, the address B will get translated to the host name, even though B is not in the DNS. The resolving works this way on a Windows machine.
> - During the connection, the host name will get resolved by DNS to address A and the test will try to connect through address A. The connection will be refused, or worse, might connect to another instance on the same machine.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1758) web console: move
 unauthorised access to model window
In-Reply-To: <JIRA.12497313.1374744166000@Atlassian.JIRA>
References: <JIRA.12497313.1374744166000@Atlassian.JIRA>
	<JIRA.12497313.1374744166000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497313.1374744166000.90069.1512580823017@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1758:
-----------------------------
    Fix Version/s: 9.0.0.Final


> web console: move unauthorised access to model window
> -----------------------------------------------------
>
>                 Key: WFLY-1758
>                 URL: https://issues.jboss.org/browse/WFLY-1758
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 9.0.0.Final
>
>
> to retain the current operation context



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3293) Excessive ERROR logging on
 JBAS014559: Invocation cannot proceed as component is shutting dow
In-Reply-To: <JIRA.12539164.1398498651000@Atlassian.JIRA>
References: <JIRA.12539164.1398498651000@Atlassian.JIRA>
	<JIRA.12539164.1398498651000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539164.1398498651000.90074.1512580823117@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3293:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Excessive ERROR logging on JBAS014559: Invocation cannot proceed as component is shutting dow
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3293
>                 URL: https://issues.jboss.org/browse/WFLY-3293
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Thomas Fr?hbeck
>            Assignee: David Lloyd
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> on server shutdown excessive ERROR logs are produced related to EJB invocations on beans in state shutdown.
> 2014-04-26 09:38:43,059 ERROR [org.jboss.as.ejb3.invocation] (ServerService Thread Pool -- 377) JBAS014134: EJB Invocation failed on component SMSQueueConsumer for method public void at.telekom.sms.esms.service.
> common.queue.SMSQueueConsumer.stopping(): org.jboss.as.ejb3.component.EJBComponentUnavailableException: JBAS014559: Invocation cannot proceed as component is shutting down
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:59) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> IMHO this is definitely no error and is very alarming for production environments, INFO w/o stacktrace, in level DEBUG full stacktrace would suffice.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:20:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4580) Lifecycle interceptors do not
	work
In-Reply-To: <JIRA.12570580.1430730696000@Atlassian.JIRA>
References: <JIRA.12570580.1430730696000@Atlassian.JIRA>
	<JIRA.12570580.1430730696000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570580.1430730696000.90078.1512580823192@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4580:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Lifecycle interceptors do not work
> ----------------------------------
>
>                 Key: WFLY-4580
>                 URL: https://issues.jboss.org/browse/WFLY-4580
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: JBoss AS7 7.1.1.Final, 8.2.0.Final
>            Reporter: Xavier Dury
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.Final
>
>
> I've been trying to use lifecycle interceptors (intercepting PostConstruct and PreDestroy, see https://issues.jboss.org/browse/WELD-1346 for reference) in my project and those do not seem to work at all (nor on enterprise managed beans nor on regular CDI managed beans).
> I tried on both JBoss AS 7.1.1 and Wildfly 8.2.0 but lifecycle interceptors are never called while other interceptors (AroundInvoke) are.
> I tested the same code on OpenEJB and it works.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2869) Incorrect closing of JMS
 connections causes subsequent tests to fail
In-Reply-To: <JIRA.12531208.1391601745000@Atlassian.JIRA>
References: <JIRA.12531208.1391601745000@Atlassian.JIRA>
	<JIRA.12531208.1391601745000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531208.1391601745000.90082.1512580823266@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2869:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Incorrect closing of JMS connections causes subsequent tests to fail
> --------------------------------------------------------------------
>
>                 Key: WFLY-2869
>                 URL: https://issues.jboss.org/browse/WFLY-2869
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 9.0.0.Final
>
>
> RunAsMDBUnitTestCase and GetCallerPrincipalTestCase call stop() to close a JMS connection, which is wrong, it should use close(). This causes the later running AuthenticationTestCase.testAuthentication_ReAuth_ViaServlet (or potentially other tests) to fail due to a timeout, having this in the log:
> {noformat}
> 0m19:53:28,973 INFO [org.jboss.arquillian.testenricher.cdi.container.BeanManagerProducer] (pool-1-thread-1) BeanManager not found.
> [0m[33m19:53:29,218 WARN [org.hornetq.core.client] (Finalizer) HQ212016: I am closing a core ClientSession you left open. Please make sure you close all ClientSessions explicitly before letting them go out of scope! 28,182,273: java.lang.Exception
> at org.hornetq.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:91)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:912)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:317)
> at org.hornetq.jms.client.HornetQConnection.authorize(HornetQConnection.java:648)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:676)
> at org.hornetq.jms.client.HornetQConnectionFactory.createQueueConnection(HornetQConnectionFactory.java:119)
> at org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase.testMDBLifecycle(GetCallerPrincipalTestCase.java:300)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214)
> at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) [:1.7.0_45]
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) [rt.jar:1.7.0_45]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) [rt.jar:1.7.0_45]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1469)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:730)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:952)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:20:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4443) Regression in 2PC
In-Reply-To: <JIRA.12566275.1426705293000@Atlassian.JIRA>
References: <JIRA.12566275.1426705293000@Atlassian.JIRA>
	<JIRA.12566275.1426705293000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566275.1426705293000.90088.1512580823392@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4443:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Regression in 2PC
> -----------------
>
>                 Key: WFLY-4443
>                 URL: https://issues.jboss.org/browse/WFLY-4443
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 9.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Tom Jenkinson
>             Fix For: 9.0.0.Final
>
>
> I compiled the latest WildFly snapshot and now have a regression compared with the snapshot
> from March 13. Maybe it is related to https://github.com/wildfly/wildfly/commit/dae2b07610205264fb85c0021684b1f9d563773c
> which was merged on March 13.
> Using Hibernate I'm persisting a simple object into an XA datasource (there is another 2nd XA datasource in
> standalone.xml which isn't used during the failing transaction). This new Java object
> doesn't reference another object, and isn't referenced by any other object. Invoking
> EntityManager.persist() via Hibernate works fine. However, during Commit (via @Transactional
> as a CDI interceptor) I'm getting the following exception and stacktrace:
> {code}
> 2015-03-18 19:44:29,267 WARN  [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a83801:3620239c:5509c313:57, org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList at 6112018f >: java.util.ConcurrentModificationException
> 	at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> 	at java.util.ArrayList$Itr.next(ArrayList.java:851)
> 	at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:90)
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371)
> 	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:75)
> 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:173)
> 	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:434)
> 	at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:42)
> 	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.weldx.transaction.UserTransaction$215414646$Proxy$_$$_Weld$Proxy$.commit(Unknown Source)
> 	at de.shop.artikelverwaltung.business.ArtikelBrokerTest.save(ArtikelBrokerTest.java:78)
> 	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.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.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.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:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	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.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner$Proxy$_$$_WeldSubclass.executeTest(Unknown Source)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner$Proxy$_$$_WeldSubclass.execute(Unknown Source)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner$Proxy$_$$_WeldSubclass.doGet(Unknown Source)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner$Proxy$_$$_WeldSubclass.service(Unknown Source)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner$Proxy$_$$_WeldSubclass.service$$super(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.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51)
> 	at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:79)
> 	at org.jboss.weld.probe.InvocationMonitor.monitor(InvocationMonitor.java:105)
> 	at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:86)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:58)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner$Proxy$_$$_WeldSubclass.service(Unknown Source)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:151)
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> 	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:70)
> 	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:278)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:255)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> 	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(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1929) TransactionalInterceptorBase
 doesn't implement Serializable
In-Reply-To: <JIRA.12499214.1377186519000@Atlassian.JIRA>
References: <JIRA.12499214.1377186519000@Atlassian.JIRA>
	<JIRA.12499214.1377186519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499214.1377186519000.90097.1512580823600@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1929:
-----------------------------
    Fix Version/s: 9.0.0.Final


> TransactionalInterceptorBase doesn't implement Serializable
> -----------------------------------------------------------
>
>                 Key: WFLY-1929
>                 URL: https://issues.jboss.org/browse/WFLY-1929
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Paul Robinson
>             Fix For: 9.0.0.Final
>
>
> I just downloaded the latest WildFly snapshot which contains an upgrade of IronJacamar. The annotation @Transactional works fine for @RequestScoped requests (see WFLY-1496).
> However, if I'm using @SessionScoped for CDI beans in a JSF-based web application, then I get the stacktrace below. The solution is pretty simple:
> The interceptor class TransactionalInterceptorBase in Narayana's package com.arjuna.ats.jta.cdi.transactional has to implement the interface java.io.Serializable.
> The stacktrace:
> {code}
> 17:25:52,861 ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop2.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop2.war".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	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.jboss.weld.exceptions.DeploymentException: WELD-001527 Managed bean declaring a passivating scope has a non-serializable interceptor.  Bean:  Managed Bean [class de.shop.auth.web.AuthModel] with qualifiers [@Default @Any @Named]  Interceptor: org.jboss.weld.interceptor.reader.DefaultInterceptorMetadata at 63abbf61
> 	at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:214)
> 	at org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:115)
> 	at org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:122)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:129)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:120)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	... 3 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2385) Resource adapter recovery
 doesn't allow fallback to security credentials
In-Reply-To: <JIRA.12508796.1382702010000@Atlassian.JIRA>
References: <JIRA.12508796.1382702010000@Atlassian.JIRA>
	<JIRA.12508796.1382702010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508796.1382702010000.90101.1512580823685@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2385:
-----------------------------
    Fix Version/s: 9.0.0.Final


>  Resource adapter recovery doesn't allow fallback to security credentials
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2385
>                 URL: https://issues.jboss.org/browse/WFLY-2385
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933000@Atlassian.JIRA>
References: <JIRA.12508208.1382112933000@Atlassian.JIRA>
	<JIRA.12508208.1382112933000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933000.90108.1512580823870@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2338:
-----------------------------
    Fix Version/s: 9.0.0.Final


> When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2338
>                 URL: https://issues.jboss.org/browse/WFLY-2338
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>         Attachments: 0001-patching-servicename-for-ds-dependency.patch
>
>
> It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881
> It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4175) Upgrade Narayana to
	5.0.4.Final
In-Reply-To: <JIRA.12559331.1418310344000@Atlassian.JIRA>
References: <JIRA.12559331.1418310344000@Atlassian.JIRA>
	<JIRA.12559331.1418310344000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559331.1418310344000.90113.1512580823970@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4175:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Upgrade Narayana to 5.0.4.Final
> -------------------------------
>
>                 Key: WFLY-4175
>                 URL: https://issues.jboss.org/browse/WFLY-4175
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3014) jboss-web schema not hosted
 at http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd
In-Reply-To: <JIRA.12533267.1393342875000@Atlassian.JIRA>
References: <JIRA.12533267.1393342875000@Atlassian.JIRA>
	<JIRA.12533267.1393342875000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533267.1393342875000.90119.1512580824082@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3014:
-----------------------------
    Fix Version/s: 9.0.0.Final


> jboss-web schema not hosted at http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-3014
>                 URL: https://issues.jboss.org/browse/WFLY-3014
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Final
>         Environment: Not applicable
>            Reporter: Ray DeCampo
>            Assignee: ehsavoie Hugonnet
>            Priority: Minor
>              Labels: xml, xml_schema
>             Fix For: 9.0.0.Final
>
>
> The docs/schema/jboss-web_8_0.xsd file included with WildFly 8.0.0.Final indicates that the schema location is http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd.  However, that URI does not return the schema file but a 404 instead (see http://www.jboss.org/j2ee/schema/ for a listing of the files there).
> The file should be hosted where the schema document indicates or the schema should be updated to reflect the proper URI of the schema.  Without it third party tools cannot assist in ensuring that the XML is well-formed.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2401)
 org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails
In-Reply-To: <JIRA.12508924.1383033520000@Atlassian.JIRA>
References: <JIRA.12508924.1383033520000@Atlassian.JIRA>
	<JIRA.12508924.1383033520000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508924.1383033520000.90124.1512580824183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2401:
-----------------------------
    Fix Version/s: 9.0.0.Final


> org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails
> --------------------------------------------------------------
>
>                 Key: WFLY-2401
>                 URL: https://issues.jboss.org/browse/WFLY-2401
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Emanuel Muckenhuber
>             Fix For: 9.0.0.Final
>
>         Attachments: org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testReadAttributeWildcards(org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1783) IIOPNamingTestCase is failing
 when run on IBM JDK
In-Reply-To: <JIRA.12497581.1375186193000@Atlassian.JIRA>
References: <JIRA.12497581.1375186193000@Atlassian.JIRA>
	<JIRA.12497581.1375186193000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497581.1375186193000.90128.1512580824313@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1783:
-----------------------------
    Fix Version/s: 9.0.0.Final


> IIOPNamingTestCase is failing when run on IBM JDK
> -------------------------------------------------
>
>                 Key: WFLY-1783
>                 URL: https://issues.jboss.org/browse/WFLY-1783
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>         Environment: ibm jdk
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>             Fix For: 9.0.0.Final
>
>
> Testcase org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase is failing when is run on IBM JDK with message
> Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> The stack trace:
> {code}
> java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
>  at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:356)
>  at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:148)
>  at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:65)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>  at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>  at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>  at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>  at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>  at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>  at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>  at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>  at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>  at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>  at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>  at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>  at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>  at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>  at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>  at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>  at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>  at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>  at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>  at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>  at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>  at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>  at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>  at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>  at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>  at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>  at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>  at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> {code}
> The reason seem to be that the stubs are not generated. As I found there is no option to force jdk generate stubs on the fly (oracle jdk knows -Dcom.sun.CORBA.ORBUseDynamicStub=true) and the generation of stubs have to be done manually e.g. with rmic tool.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1648) Access control response
	inconsistencies
In-Reply-To: <JIRA.12495786.1373008864000@Atlassian.JIRA>
References: <JIRA.12495786.1373008864000@Atlassian.JIRA>
	<JIRA.12495786.1373008864000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495786.1373008864000.90132.1512580824390@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1648:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Access control response inconsistencies
> ---------------------------------------
>
>                 Key: WFLY-1648
>                 URL: https://issues.jboss.org/browse/WFLY-1648
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>             Fix For: 9.0.0.Final
>
>
> See 
> a) https://gist.github.com/heiko-braun/5932594
> b) https://gist.github.com/heiko-braun/5932604
> Questions: 
> - in b) line 35: Why is there an additional nested "result" element?
> - in b) line 99: Why is the "access-control" element empty?
> (both cases need top be compared with a. )



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1035)
 jboss-javaee6-webapp-archetype : upgrade hibernate-jpamodelgen and
 hibernate-jpa-2.0-api for .factorypath
In-Reply-To: <JIRA.12463487.1333791965000@Atlassian.JIRA>
References: <JIRA.12463487.1333791965000@Atlassian.JIRA>
	<JIRA.12463487.1333791965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463487.1333791965000.90139.1512580824590@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1035:
-----------------------------
    Fix Version/s: 9.0.0.Final


> jboss-javaee6-webapp-archetype : upgrade hibernate-jpamodelgen and hibernate-jpa-2.0-api for .factorypath
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1035
>                 URL: https://issues.jboss.org/browse/WFLY-1035
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Fred Bricon
>            Assignee: Pete Muir
>             Fix For: 9.0.0.Final
>
>         Attachments: factorypath.pdf
>
>
> hibernate-jpamodelgen has version 1.1.1.Final, and version 1.2.0.Final is available.
> hibernate-jpa-2.0-api has version 1.0.0.Final, and version 1.0.1.Final is available.
> I'll attach a screenshot to illustrate the current settings for .factorypath.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3944) Broken integration between
 messaging subsystem and jgroups subsystem
In-Reply-To: <JIRA.12554406.1412694785000@Atlassian.JIRA>
References: <JIRA.12554406.1412694785000@Atlassian.JIRA>
	<JIRA.12554406.1412694785000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554406.1412694785000.90145.1512580824750@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3944:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Broken integration between messaging subsystem and jgroups subsystem
> --------------------------------------------------------------------
>
>                 Key: WFLY-3944
>                 URL: https://issues.jboss.org/browse/WFLY-3944
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 9.0.0.Final
>
>
> The integration between messaging and jgroups is currently broken. My guess is this was due to recent changes in clustering.
> To reproduce it change the bg-group1 element in standalone-full-ha.xml to replace the socket-binding element with the following:
> {code}
> 	                <jgroups-stack>udp</jgroups-stack>
> 	                <jgroups-channel>hq-bg</jgroups-channel>
>                         <!--<socket-binding>messaging-group</socket-binding>-->
> {code}
> At boot this appears in the logs:
> {code}
> 10:00:58,707 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging.default is missing [jboss.jgroups.stack.udp]"]}
> 10:00:58,930 INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184:    New missing/unsatisfied dependencies:
>       service jboss.jgroups.stack.udp (missing) dependents: [service jboss.messaging.default] 
> {code}
> WFLY-3943 is about the lack of testing of this integration,



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4191) Provide cheatsheet.xml for
 Kitchensink Quickstarts
In-Reply-To: <JIRA.12559883.1418939016000@Atlassian.JIRA>
References: <JIRA.12559883.1418939016000@Atlassian.JIRA>
	<JIRA.12559883.1418939016000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559883.1418939016000.90148.1512580824810@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4191:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Provide cheatsheet.xml for Kitchensink Quickstarts
> --------------------------------------------------
>
>                 Key: WFLY-4191
>                 URL: https://issues.jboss.org/browse/WFLY-4191
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Rafael Benevides
>            Assignee: Rafael Benevides
>              Labels: quickstart, quickstarts
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3070) The download link for Wildfly
 at http://www.jboss.org/projects is broken
In-Reply-To: <JIRA.12534167.1394028866000@Atlassian.JIRA>
References: <JIRA.12534167.1394028866000@Atlassian.JIRA>
	<JIRA.12534167.1394028866000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534167.1394028866000.90153.1512580824940@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3070:
-----------------------------
    Fix Version/s: 9.0.0.Final


> The download link for Wildfly at http://www.jboss.org/projects is broken
> ------------------------------------------------------------------------
>
>                 Key: WFLY-3070
>                 URL: https://issues.jboss.org/browse/WFLY-3070
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Karel Piwko
>            Assignee: Tomaz Cerar
>             Fix For: 9.0.0.Final
>
>
> The link currently points to http://www.wildfly.org/download/, however should actually be http://wildfly.org/downloads/.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2515) JBAS014249 if a fire and
 forget asynchronous ejb call is made
In-Reply-To: <JIRA.12525253.1384513753000@Atlassian.JIRA>
References: <JIRA.12525253.1384513753000@Atlassian.JIRA>
	<JIRA.12525253.1384513753000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525253.1384513753000.90158.1512580825051@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2515:
-----------------------------
    Fix Version/s: 9.0.0.Final


> JBAS014249 if a fire and forget asynchronous ejb call is made
> -------------------------------------------------------------
>
>                 Key: WFLY-2515
>                 URL: https://issues.jboss.org/browse/WFLY-2515
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1, 8.0.0.CR1
>         Environment: Beta2 SNAPSHOT
>            Reporter: Wolf-Dieter Fink
>            Assignee: David Lloyd
>             Fix For: 9.0.0.Final
>
>
> If an ejb method 
> @Asynchronous void fireAndForget(...)
> is called remote and the client disconnect an Exception JBAS014249 will be thrown if the async method return.
> {noformat}
> ERROR [org.jboss.as.ejb3] (EJB default - 1) JBAS014249: Error invoking method public abstract void org.jboss.as.quickstarts.ejb.asynchronous.AsynchronousAccess.fireAndForget(long) on bean named AsynchronousAccessBean for appname  modulename jboss-as-ejb-asynchronous-ejb distinctname : java.lang.NullPointerException
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	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]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> 11:30:20,242 ERROR [org.jboss.as.ejb3] (EJB default - 1) JBAS014250: Could not write method invocation failure for method public abstract void org.jboss.as.quickstarts.ejb.asynchronous.AsynchronousAccess.fireAndForget(long) on bean named AsynchronousAccessBean for appname  modulename jboss-as-ejb-asynchronous-ejb distinctname  due to: java.io.IOException: JBAS014560: Could not open message outputstream for writing to Channel
> 	at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler.writeException(AbstractMessageHandler.java:102)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$400(MethodInvocationMessageHandler.java:70)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:213)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	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]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: org.jboss.remoting3.NotOpenException: Writes closed
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:112)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:301)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.ChannelAssociation.acquireChannelMessageOutputStream(ChannelAssociation.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler.writeException(AbstractMessageHandler.java:100)
> 	... 9 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1764) Web Console: Remaining
 @AccessControl declarations
In-Reply-To: <JIRA.12497399.1374838693000@Atlassian.JIRA>
References: <JIRA.12497399.1374838693000@Atlassian.JIRA>
	<JIRA.12497399.1374838693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497399.1374838693000.90161.1512580825123@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1764:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Web Console: Remaining @AccessControl declarations
> --------------------------------------------------
>
>                 Key: WFLY-1764
>                 URL: https://issues.jboss.org/browse/WFLY-1764
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 9.0.0.Final
>
>
> These are still missing:
> {noformat}
> DataSourceMetricPresenter(#ds-metrics) is missing @AccessControl annotation!
> EnvironmentPresenter(#environment) is missing @AccessControl annotation!
> JMSMetricPresenter(#jms-metrics) is missing @AccessControl annotation!
> JPAMetricPresenter(#jpa-metrics) is missing @AccessControl annotation!
> JndiPresenter(#naming) is missing @AccessControl annotation!
> TXLogPresenter(#tx-logs) is missing @AccessControl annotation!
> TXMetricPresenter(#tx-metrics) is missing @AccessControl annotation!
> OSGiConfigurationPresenter(#osgi-configuration) is missing @AccessControl annotation!
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4666) Add smoke test for
	jaxrs-client
In-Reply-To: <JIRA.12572556.1432541199000@Atlassian.JIRA>
References: <JIRA.12572556.1432541199000@Atlassian.JIRA>
	<JIRA.12572556.1432541199000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572556.1432541199000.90164.1512580825228@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4666:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Add smoke test for jaxrs-client 
> --------------------------------
>
>                 Key: WFLY-4666
>                 URL: https://issues.jboss.org/browse/WFLY-4666
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Katerina Novotna
>            Assignee: Katerina Novotna
>             Fix For: 9.0.0.Final
>
>
> https://issues.jboss.org/browse/EAP7-318 is adding resteasy-client.
> This test serves as basic smoke tests to be run within the testsuite.
> *BasicClientTestCase*:
> * creates instance of resteasy client
> * sends GET, POST, PUT and DELETE requests to the server
> * verifies the answer from the server



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1432) ClassCastException when JBoss
 LogManager is initialized before the logging subsystem expects
In-Reply-To: <JIRA.12493339.1370021199000@Atlassian.JIRA>
References: <JIRA.12493339.1370021199000@Atlassian.JIRA>
	<JIRA.12493339.1370021199000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493339.1370021199000.90171.1512580825451@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1432:
-----------------------------
    Fix Version/s: 9.0.0.Final


> ClassCastException when JBoss LogManager is initialized before the logging subsystem expects
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1432
>                 URL: https://issues.jboss.org/browse/WFLY-1432
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Kyle Lape
>            Assignee: James Perkins
>             Fix For: 9.0.0.Final
>
>
> When making the following modifications to put JBoss LogManager on the boot classpath to make it available to Java agents:
> {noformat}
> diff --git a/bin/standalone.conf b/bin/standalone.conf
> index 97895a5..9517129 100644
> --- a/bin/standalone.conf
> +++ b/bin/standalone.conf
>  -35,7 +35,7 @@
>  #JAVA=""
>  
>  if [ "x$JBOSS_MODULES_SYSTEM_PKGS" = "x" ]; then
> -   JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
> +   JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager,org.jboss.logmanager.config,org.jboss.logmanager.errormanager,org.jboss.logmanager.filters,org.jboss.logmanager.formatters,org.jboss.logmanager.handlers"
>  fi
>  
>  # Uncomment the following line to prevent manipulation of JVM options
>  -48,7 +48,7 @@ fi
>  #
>  if [ "$JAVA_OPTS" = "x" ]; then
>     JAVA_OPTS="-Xms1303m -Xmx1303m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true"
> -   JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
> +   JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/p:$JBOSS_HOME/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-1.4.0.Final-redhat-1.jar -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true -Dcom.sun.management.jmxremote=x -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
>  else
>     echo "JAVA_OPTS already set in environment; overriding default settings with values: $JAVA_OPTS"
>  fi
> {noformat}
> I get the following error:
> {noformat}
> 09:28:18,984 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 5) JBAS014612: Operation ("add") failed - address: ([
>     ("subsystem" => "logging"),
>     ("console-handler" => "CONSOLE")
> ]): java.lang.ClassCastException: org.jboss.logmanager.PropertyConfigurator cannot be cast to org.jboss.as.logging.logmanager.ConfigurationPersistence
>         at org.jboss.as.logging.logmanager.ConfigurationPersistence.getOrCreateConfigurationPersistence(ConfigurationPersistence.java:93)
>         at org.jboss.as.logging.logmanager.ConfigurationPersistence.getOrCreateConfigurationPersistence(ConfigurationPersistence.java:81)
>         at org.jboss.as.logging.LoggingOperations$LoggingOperationStepHandler.execute(LoggingOperations.java:154)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:334) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [classes.jar:1.6.0_45]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [classes.jar:1.6.0_45]
>         at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_45]
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2198) Remote Naming throws the same
 exception for different causes
In-Reply-To: <JIRA.12501957.1380669681000@Atlassian.JIRA>
References: <JIRA.12501957.1380669681000@Atlassian.JIRA>
	<JIRA.12501957.1380669681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501957.1380669681000.90177.1512580825597@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2198:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Remote Naming throws the same exception for different causes
> ------------------------------------------------------------
>
>                 Key: WFLY-2198
>                 URL: https://issues.jboss.org/browse/WFLY-2198
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>             Fix For: 9.0.0.Final
>
>
> A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.
> We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. 
> If all the the servers specified are not not running:
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> If one of the servers is running, but the client's username/password are incorrect
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4009) Cannot externalise camel-cdi
	& deltaspike
In-Reply-To: <JIRA.12555835.1414016023000@Atlassian.JIRA>
References: <JIRA.12555835.1414016023000@Atlassian.JIRA>
	<JIRA.12555835.1414016023000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555835.1414016023000.90181.1512580825712@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4009:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Cannot externalise camel-cdi & deltaspike
> -----------------------------------------
>
>                 Key: WFLY-4009
>                 URL: https://issues.jboss.org/browse/WFLY-4009
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.1.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.Final
>
>
> Currently, there is a webapp deployed as part of the camel subsystem that contains
> * camel-cdi
> * deltaspike-core-api
> * deltaspike-core-impl
> * deltaspike-cdictrl-api
> Generally it seems that every webapp needs to package these in order for camel-cdi to work. We would however like to replace these embedded jars with references to the already existing modules.
> GitHub Issue: https://github.com/tdiesler/wildfly-camel/issues/15



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4267) Add Archetype integration
 test for HTML5 archetype
In-Reply-To: <JIRA.12561220.1421706749000@Atlassian.JIRA>
References: <JIRA.12561220.1421706749000@Atlassian.JIRA>
	<JIRA.12561220.1421706749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561220.1421706749000.90184.1512580825795@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4267:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Add Archetype integration test for HTML5 archetype
> --------------------------------------------------
>
>                 Key: WFLY-4267
>                 URL: https://issues.jboss.org/browse/WFLY-4267
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Rafael Benevides
>            Assignee: Rafael Benevides
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3813) Upgrade Narayana to
	5.0.3.Final
In-Reply-To: <JIRA.12551115.1409840876000@Atlassian.JIRA>
References: <JIRA.12551115.1409840876000@Atlassian.JIRA>
	<JIRA.12551115.1409840876000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551115.1409840876000.90223.1512580826843@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3813:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Upgrade Narayana to 5.0.3.Final
> -------------------------------
>
>                 Key: WFLY-3813
>                 URL: https://issues.jboss.org/browse/WFLY-3813
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 9.0.0.Final
>
>
> This is useful for JBCTS-1387



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2371)
 SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger
 than allowed size"
In-Reply-To: <JIRA.12508645.1382597019000@Atlassian.JIRA>
References: <JIRA.12508645.1382597019000@Atlassian.JIRA>
	<JIRA.12508645.1382597019000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508645.1382597019000.90227.1512580827044@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2371:
-----------------------------
    Fix Version/s: 9.0.0.Final


> SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size"
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2371
>                 URL: https://issues.jboss.org/browse/WFLY-2371
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>             Fix For: 9.0.0.Final
>
>
> The test org.jboss.as.test.integration.logging.operations.SizeRotatingHandlerTestCase.rotationTest consistently fails with:
> java.lang.AssertionError: This file is bigger than allowed rotate-size: size-rotating-reload-rotationTest.log.1
> Link to job:
> https://jenkins.mw.lab.eng.bos.redhat.com/job/eap-6x-manu-acceptance-as-ts-RHEL6_x86-oracleJDK6-srczip/25/testReport/junit/org.jboss.as.test.integration.logging.operations/SizeRotatingHandlerTestCase/rotationTest/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3688) datasources subsystem:
 datasource and xa-datasource properties do not support the use of multiple
 values for one property
In-Reply-To: <JIRA.12547780.1406646849000@Atlassian.JIRA>
References: <JIRA.12547780.1406646849000@Atlassian.JIRA>
	<JIRA.12547780.1406646849000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547780.1406646849000.90232.1512580827174@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3688:
-----------------------------
    Fix Version/s: 9.0.0.Final


> datasources subsystem: datasource and xa-datasource properties do not support the use of multiple values for one property
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3688
>                 URL: https://issues.jboss.org/browse/WFLY-3688
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.1.0.Final
>            Reporter: Tom Fonteyne
>            Assignee: Jeff Zhang
>             Fix For: 9.0.0.Final
>
>
> The oracle JDBC driver had a method:
>        setConnectionProperties(java.util.Properties value)
> which is needed to set several connection properties for datasources.
> Most (all?) of these connection properties do not have individual setters.
> WildFly does not support setting a "Properties" value for "datasource-property"



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3721) CommandDispatcher hides
	exceptions
In-Reply-To: <JIRA.12548914.1407449266000@Atlassian.JIRA>
References: <JIRA.12548914.1407449266000@Atlassian.JIRA>
	<JIRA.12548914.1407449266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12548914.1407449266000.90238.1512580827487@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3721:
-----------------------------
    Fix Version/s: 9.0.0.Final


> CommandDispatcher hides exceptions
> ----------------------------------
>
>                 Key: WFLY-3721
>                 URL: https://issues.jboss.org/browse/WFLY-3721
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 8.1.0.Final
>            Reporter: Rich DiCroce
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.Final
>
>
> The implementations of CommandDispatcher#submitOnCluster and #executeOnCluster completely hide any exceptions that occur while trying to send the command. This makes it very difficult to debug things like serialization exceptions. (Note: In the 8.x branch, the implementation is in ServiceCommandDispatcher. In master, it has moved to ChannelCommandDispatcher, but the code is essentially the same and the issue still exists.)
> Instead of hiding the exception, the implementation should expose the exception to the developer in some way. A couple possibilities:
> - Don't catch the exception.
> - Catch the exception and return a Map with one entry, where the key is the local node and the value is a Future or CommandResponse that contains the exception.
> - Catch the exception and return an empty map, but also log the exception.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3606) Porting to IronJacamar
	1.2.Beta3
In-Reply-To: <JIRA.12546025.1404984493000@Atlassian.JIRA>
References: <JIRA.12546025.1404984493000@Atlassian.JIRA>
	<JIRA.12546025.1404984493000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546025.1404984493000.90241.1512580827653@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3606:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Porting to IronJacamar 1.2.Beta3
> --------------------------------
>
>                 Key: WFLY-3606
>                 URL: https://issues.jboss.org/browse/WFLY-3606
>             Project: WildFly
>          Issue Type: Task
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:27 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:27 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1781) XTS subsystem doesn't list
 the DUP phase order in Phase.java
In-Reply-To: <JIRA.12497576.1375180811000@Atlassian.JIRA>
References: <JIRA.12497576.1375180811000@Atlassian.JIRA>
	<JIRA.12497576.1375180811000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497576.1375180811000.90247.1512580827882@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1781:
-----------------------------
    Fix Version/s: 9.0.0.Final


> XTS subsystem doesn't list the DUP phase order in Phase.java
> ------------------------------------------------------------
>
>                 Key: WFLY-1781
>                 URL: https://issues.jboss.org/browse/WFLY-1781
>             Project: WildFly
>          Issue Type: Bug
>          Components: XTS
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: jaikiran pai
>            Assignee: Paul Robinson
>             Fix For: 9.0.0.Final
>
>
> https://github.com/wildfly/wildfly/blob/master/xts/src/main/java/org/jboss/as/xts/XTSSubsystemAdd.java#L172 does:
> {code}
> processorTarget.addDeploymentProcessor(XTSExtension.SUBSYSTEM_NAME, Phase.POST_MODULE, Phase.POST_MODULE_WELD_PORTABLE_EXTENSIONS + 10, new CDIExtensionProcessor());
> {code}
> The phase number should all be centrally maintained in Phase.java so that those can be tracked.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4031) Wildfly Quickstarts using old
 namespaces for beans.xml, faces-config.xml and persistence.xml
In-Reply-To: <JIRA.12556304.1414632990000@Atlassian.JIRA>
References: <JIRA.12556304.1414632990000@Atlassian.JIRA>
	<JIRA.12556304.1414632990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556304.1414632990000.90251.1512580828047@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4031:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Wildfly Quickstarts using old namespaces for beans.xml, faces-config.xml and persistence.xml
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4031
>                 URL: https://issues.jboss.org/browse/WFLY-4031
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rafael Benevides
>            Assignee: Rafael Benevides
>            Priority: Minor
>              Labels: quickstarts,
>             Fix For: 9.0.0.Final
>
>
> All Wildfly  quickstarts have the wrong XML namespaces for the following files.
> ./src/main/webapp/WEB-INF/beans.xml
> ./src/main/webapp/WEB-INF/faces-config.xml
> beans.xml and faces-config.xml are using java.sun.com-style namespaces instead of xmlns.jcp.org-style namespaces.
> This affects the wildfly archetypes as well



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1946) Severe error on deploy of
 ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
In-Reply-To: <JIRA.12499318.1377383557000@Atlassian.JIRA>
References: <JIRA.12499318.1377383557000@Atlassian.JIRA>
	<JIRA.12499318.1377383557000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499318.1377383557000.90261.1512580828378@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1946:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Severe error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-1946
>                 URL: https://issues.jboss.org/browse/WFLY-1946
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>             Fix For: 9.0.0.Final
>
>         Attachments: Jira-WFLY-1946.tar
>
>
> Deploy of test.ear shows a severe error:
> 00:23:21,917 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "test.ear" (runtime-name: "test.ear")
> 00:23:21,941 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "null" (runtime-name: "web.war")
> 00:23:21,942 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "null" (runtime-name: "ejb.jar")
> 00:23:22,080 INFO  [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment test.ear
> 00:23:22,121 INFO  [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment ejb.jar
> 00:23:22,141 INFO  [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment web.war
> 00:23:22,157 INFO  [org.jboss.weld.deployer#deploy] JBAS016005: Starting Services for CDI deployment: test.ear
> 00:23:22,192 INFO  [org.jboss.weld.deployer#start] JBAS016008: Starting weld service for deployment test.ear
> 00:23:22,734 SEVERE [javax.enterprise.resource.webcontainer.jsf.flow#afterBeanDiscovery] Unable to obtain CDI 1.1 utilities for Mojarra
> 00:23:22,753 SEVERE [javax.enterprise.resource.webcontainer.jsf.application.view#afterBeanDiscovery] Unable to obtain CDI 1.1 utilities for Mojarra
> 00:23:23,099 INFO  [test.web.Startup#contextInitialized] contextInitialized
> 00:23:23,405 INFO  [org.wildfly.extension.undertow#registerDeployment] JBAS018210: Register web context: /intern/web
> 00:23:23,465 INFO  [org.jboss.as.server#handleResult] JBAS018559: Deployed "test.ear" (runtime-name : "test.ear")
> Although everything seems to be fine. App works without errors.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1765) JDBC object store does not
 change LOG_STORE_TYPE attribute
In-Reply-To: <JIRA.12497402.1374839437000@Atlassian.JIRA>
References: <JIRA.12497402.1374839437000@Atlassian.JIRA>
	<JIRA.12497402.1374839437000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497402.1374839437000.90267.1512580828504@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1765:
-----------------------------
    Fix Version/s: 9.0.0.Final


> JDBC object store does not change LOG_STORE_TYPE attribute
> ----------------------------------------------------------
>
>                 Key: WFLY-1765
>                 URL: https://issues.jboss.org/browse/WFLY-1765
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 9.0.0.Final
>
>
> The transaction subsystem when set up to JDBC object store should keep a note about it in log-store-type attribute as HornetQ object store does. It seems not to be consistent when one object store does this, but others do not.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4171) Provide an html5 archetype
	for wildfly
In-Reply-To: <JIRA.12559175.1418226929000@Atlassian.JIRA>
References: <JIRA.12559175.1418226929000@Atlassian.JIRA>
	<JIRA.12559175.1418226929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559175.1418226929000.90272.1512580828707@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4171:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Provide an html5 archetype for wildfly
> --------------------------------------
>
>                 Key: WFLY-4171
>                 URL: https://issues.jboss.org/browse/WFLY-4171
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Fred Bricon
>            Assignee: Rafael Benevides
>             Fix For: 9.0.0.Final
>
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are : 
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final 
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3369) Performance issue of
 jaxws-client on JDK 1.7.0_55
In-Reply-To: <JIRA.12541061.1400468780000@Atlassian.JIRA>
References: <JIRA.12541061.1400468780000@Atlassian.JIRA>
	<JIRA.12541061.1400468780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541061.1400468780000.90279.1512580828892@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3369:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Performance issue of jaxws-client on JDK 1.7.0_55
> -------------------------------------------------
>
>                 Key: WFLY-3369
>                 URL: https://issues.jboss.org/browse/WFLY-3369
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: JBoss AS7 7.1.1.Final
>         Environment: Red Hat Enterprise 6.4, Solaris 10, JBoss AS 7.1.3
>            Reporter: Zhang Boya
>            Assignee: Jim Ma
>             Fix For: 9.0.0.Final
>
>
> Assume that  a JAX-WS deploys on somewhere else, developer generates the JAX-WS client side classes by using wsdl2java tools. These classes have been exported as 'exmaple-ws-client.jar'. When developer needs to access this JAX-WS in their web application, this JAR file would be published with WAR file together. By default, the JBoss AS would supply an instance of CXF's implementation for the JAX-WS client when web application be deployed to JBoss AS. The class name of this JAX-WS client would be 'org.apache.cxf.jaxws.JaxWsClientProxy'. The JAX-WS invocations of client side got a very bad performance since I upgraded JDK from 1.7.0_25 to 1.7.0_55, especially on Solaris.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:28 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4266) Fix HTML5 quickstart minify
 profile when importing to JBDS
In-Reply-To: <JIRA.12561219.1421705407000@Atlassian.JIRA>
References: <JIRA.12561219.1421705407000@Atlassian.JIRA>
	<JIRA.12561219.1421705407000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561219.1421705407000.90282.1512580828954@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4266:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Fix HTML5 quickstart minify profile when importing to JBDS
> ----------------------------------------------------------
>
>                 Key: WFLY-4266
>                 URL: https://issues.jboss.org/browse/WFLY-4266
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rafael Benevides
>            Assignee: Rafael Benevides
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1695) Web Console: Principal/Role
 indication in footer
In-Reply-To: <JIRA.12496449.1373886112000@Atlassian.JIRA>
References: <JIRA.12496449.1373886112000@Atlassian.JIRA>
	<JIRA.12496449.1373886112000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496449.1373886112000.90285.1512580829017@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1695:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Web Console: Principal/Role indication in footer
> ------------------------------------------------
>
>                 Key: WFLY-1695
>                 URL: https://issues.jboss.org/browse/WFLY-1695
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 9.0.0.Final
>
>
> it should be possible to see the current principal and the active role in the console footer



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4313) Clean-up tests which use
 Kerberos in the WildFly testsuite
In-Reply-To: <JIRA.12562413.1423059959000@Atlassian.JIRA>
References: <JIRA.12562413.1423059959000@Atlassian.JIRA>
	<JIRA.12562413.1423059959000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562413.1423059959000.90290.1512580829246@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4313:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Clean-up tests which use Kerberos in the WildFly testsuite
> ----------------------------------------------------------
>
>                 Key: WFLY-4313
>                 URL: https://issues.jboss.org/browse/WFLY-4313
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>             Fix For: 9.0.0.Final
>
>
> Clean up Kerberos tests and add an unified logic for skipping Kerberos test configurations which proved to be unstable/buggy. By a configuration here is meant combination of Java vendor, version and IP stack.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2180) Thread threads pools inherit
 security context of submitting threads
In-Reply-To: <JIRA.12501788.1380523725000@Atlassian.JIRA>
References: <JIRA.12501788.1380523725000@Atlassian.JIRA>
	<JIRA.12501788.1380523725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501788.1380523725000.90296.1512580829405@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2180:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Thread threads pools inherit security context of submitting threads
> -------------------------------------------------------------------
>
>                 Key: WFLY-2180
>                 URL: https://issues.jboss.org/browse/WFLY-2180
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, EJB, Server, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: David Lloyd
>             Fix For: 9.0.0.Final
>
>
> Some thread pool implementation will immediately create a new thread if work is submitted and there is not enough threads available to handle it. This newly created thread will inherit the access control context of the thread that is submitting the work, which essentially means that thread pool threads have a random access control context. 
> This is the root cause of UNDERTOW-102, and likely other security manager related failures as well.
> I think that the best way to fix this is in the thread pool itself, as it should create the thread in a privileged block. We obviously cannot do this for JDK thread pools however.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4190) Provide a Willdfly banner
 instead of JBossAS7 for Kitchensink quickstarts
In-Reply-To: <JIRA.12559882.1418938891000@Atlassian.JIRA>
References: <JIRA.12559882.1418938891000@Atlassian.JIRA>
	<JIRA.12559882.1418938891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559882.1418938891000.90299.1512580829477@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4190:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Provide a Willdfly banner instead of JBossAS7  for Kitchensink quickstarts
> --------------------------------------------------------------------------
>
>                 Key: WFLY-4190
>                 URL: https://issues.jboss.org/browse/WFLY-4190
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Rafael Benevides
>            Assignee: Rafael Benevides
>              Labels: quickstart, quickstarts
>             Fix For: 9.0.0.Final
>
>         Attachments: wildfly_400x130.jpg
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3404) Major performance degradation
 from JBoss 7.1 to Wildfly 8.0.0-Final.
In-Reply-To: <JIRA.12541924.1401169524000@Atlassian.JIRA>
References: <JIRA.12541924.1401169524000@Atlassian.JIRA>
	<JIRA.12541924.1401169524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541924.1401169524000.90305.1512580829652@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3404:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final.
> --------------------------------------------------------------------
>
>                 Key: WFLY-3404
>                 URL: https://issues.jboss.org/browse/WFLY-3404
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Final
>            Reporter: Timothy Heider
>            Assignee: Jason Greene
>             Fix For: 9.0.0.Final
>
>
> I have deployed my application to Wildfly 8.0.0 Final and it is almost unusable now.  We have rolled back to JBoss 7.1 (same application WARs) and it works fine.  
> Specifically what seems to be slow is our SOAP web services are taking up to 8 to 10 seconds to respond.  We have user concurrency of probably 10-30 users at once hitting these services every 10 seconds or so.
> On JBoss 7.1 these services all respond sub-second.  The database is totally unburdened and the server is 90% idle all the time.
> We have one service endpoint that is a Comet queue wait call.  Probably 10 users are waiting on that.  Did something change between JBoss 7 and Wildfly 8 that might cause that to not work now? (e.g. too small a thread pool that blocks until the 10 second comet call breaks on a timeout?)
> We will try 8.1.0CR2 but I wanted to report we're investigating this and see if you can help us.  Thanks!



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4173) Server side EJB Handler not
 compression response
In-Reply-To: <JIRA.12559214.1418251841000@Atlassian.JIRA>
References: <JIRA.12559214.1418251841000@Atlassian.JIRA>
	<JIRA.12559214.1418251841000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559214.1418251841000.90310.1512580829877@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4173:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Server side EJB Handler not compression response
> ------------------------------------------------
>
>                 Key: WFLY-4173
>                 URL: https://issues.jboss.org/browse/WFLY-4173
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Brad Maxwell
>            Assignee: Tomas Hofman
>             Fix For: 9.0.0.Final
>
>
> When compression is enabled for request/response, the jboss-ejb-client is sending a compressed request, but the application server is responding with an uncompressed response.
> On the server enabling TRACE on org.jboss.as.ejb3, we can see the server receives a compressed request
> TRACE [org.jboss.as.ejb3] (default task-5) Got message with header 0x1b on channel Channel ID 56b01772 (inbound) of Remoting connection TRACE [org.jboss.as.ejb3.invocation] (default task-5) Received a compressed message stream
> Client side, Enabling TRACE on the client side for org.jboss.ejb.client we see it is 0x5 where it should be 0x1b
> TRACE org.jboss.ejb.client.remoting.ChannelAssociation - Received message with header 0x5



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:29 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1921) Cancel operation is ignored
 when flushing JMS destination metrics in the management console
In-Reply-To: <JIRA.12499140.1377157451000@Atlassian.JIRA>
References: <JIRA.12499140.1377157451000@Atlassian.JIRA>
	<JIRA.12499140.1377157451000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499140.1377157451000.90316.1512580829999@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1921:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Cancel operation is ignored when flushing JMS destination metrics in the management console
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1921
>                 URL: https://issues.jboss.org/browse/WFLY-1921
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Osamu Nagano
>            Assignee: Harald Pehl
>             Fix For: 9.0.0.Final
>
>
> When you push "Flush" button on JMS Destinations runtime tab (both of queues and topics), a confirmation dialog box brings up.  "Cancel" button in the dialog box is always ignored and destination flushing is inevitably executed.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4441) web.xml parser process cannot
 handle exception for xml file which does not have the encoding attribute
In-Reply-To: <JIRA.12566228.1426674849000@Atlassian.JIRA>
References: <JIRA.12566228.1426674849000@Atlassian.JIRA>
	<JIRA.12566228.1426674849000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566228.1426674849000.90319.1512580830103@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4441:
-----------------------------
    Fix Version/s: 9.0.0.Final


> web.xml parser process cannot handle exception for xml file which does not have the encoding attribute
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4441
>                 URL: https://issues.jboss.org/browse/WFLY-4441
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Tomas Hofman
>            Assignee: Tomas Hofman
>             Fix For: 9.0.0.Final
>
>
> Description copied from https://bugzilla.redhat.com/show_bug.cgi?id=1184292
> Description of problem:
> When XMLStreamException occurs by web.xml parser process for xml file which does not have the encoding attribute, e.getLocation()[1] is null. We cannot find cause of exception by NullPointerException.
> [1]
> - org.jboss.as.web.deployment.WebParsingDeploymentProcessor.java
> #115            } catch (XMLStreamException e) {
> -> #116                throw new DeploymentUnitProcessingException(MESSAGES.failToParseXMLDescriptor(webXml, e.getLocation().getLineNumber(), e.getLocation().getColumnNumber()), e);
> #117            } catch (IOException e) {
> #118                throw new DeploymentUnitProcessingException(MESSAGES.failToParseXMLDescriptor(webXml), e);
> #119            } 
> Version-Release number of selected component (if applicable):
> EAP 6.3.2
> How reproducible:
> Attached web.xml for reproducing.
> Steps to Reproduce:
> 1. Create war application using attached web.xml.
> 2. Deploy war to EAP.
> 3. Start EAP.
> Actual results:
> You can confirm NullPointerException.
> 15:56:23,190 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."test.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "test.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_71]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_71]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.web.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:116)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> 	... 5 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1808) Update transaction API 1.2 to
	1.0.0.Beta1
In-Reply-To: <JIRA.12497802.1375381954000@Atlassian.JIRA>
References: <JIRA.12497802.1375381954000@Atlassian.JIRA>
	<JIRA.12497802.1375381954000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497802.1375381954000.90323.1512580830219@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1808:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Update transaction API 1.2 to 1.0.0.Beta1
> -----------------------------------------
>
>                 Key: WFLY-1808
>                 URL: https://issues.jboss.org/browse/WFLY-1808
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1739) Certain methods
 unconditionally invokes itself and may cause infinit loop
In-Reply-To: <JIRA.12497091.1374525365000@Atlassian.JIRA>
References: <JIRA.12497091.1374525365000@Atlassian.JIRA>
	<JIRA.12497091.1374525365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497091.1374525365000.90329.1512580830391@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1739:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Certain methods unconditionally invokes itself and may cause infinit loop
> -------------------------------------------------------------------------
>
>                 Key: WFLY-1739
>                 URL: https://issues.jboss.org/browse/WFLY-1739
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.Final
>
>
> FindBugs found 2 instances of such recursive calls:
> {code:title=org.jboss.as.clustering.msc.DelegatingServiceTarget}
> @Override
>     public Set<ServiceListener<Object>> getListeners() {
>         return this.getListeners();
>     }
> {code}
> {code:title=org.wildfly.clustering.web.catalina.session.SessionFacade}
> @Override
>     public boolean isValidInternal() {
>         return this.isValidInternal();
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4224) Update all text references
 from JBoss to Wildfly on kitchensink quickstarts
In-Reply-To: <JIRA.12560340.1420565137000@Atlassian.JIRA>
References: <JIRA.12560340.1420565137000@Atlassian.JIRA>
	<JIRA.12560340.1420565137000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560340.1420565137000.90334.1512580830561@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4224:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Update all text references from JBoss to Wildfly on kitchensink quickstarts
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-4224
>                 URL: https://issues.jboss.org/browse/WFLY-4224
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Rafael Benevides
>            Assignee: Rafael Benevides
>             Fix For: 9.0.0.Final
>
>
> Kitchensink Quickstarts contains a lot of references to JBossAS7 that needs to be updated to WildFly



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:30 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4153) Incorrect interface
 definition in ejb-jar.xml for entity beans shows just NullPointer exception
In-Reply-To: <JIRA.12558692.1417682346000@Atlassian.JIRA>
References: <JIRA.12558692.1417682346000@Atlassian.JIRA>
	<JIRA.12558692.1417682346000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558692.1417682346000.90337.1512580830625@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4153:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Incorrect interface definition in ejb-jar.xml for entity beans shows just NullPointer exception
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4153
>                 URL: https://issues.jboss.org/browse/WFLY-4153
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> {noformat}
> In case that you specify interface type for entity bean in ejb-jar.xml that does not correspond with definition in the class of the bean then just Null Pointer exception is shown without any other info what's happening.
> I mean when you define bean through interface as remote and the ejb-jar.xml describes bean interfaces as local
> {code}
> public interface SomeBean extends EJBObject {
> ...
> }
> public interface SomeBeanHome extends EJBHome {
> ...
> }
> {code}
> and the ejb-jar.xml looks like
> {code}
> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" version="3.1">
>   <enterprise-beans>
>     <entity>
>       <ejb-name>SomeBean</ejb-name>
>       <local-home>package.SomeBeanHome</local-home>
>       <local>package.SomeBean</local>
>       <ejb-class>package.SomeBeanBean</ejb-class>
>       <persistence-type>Bean</persistence-type>
>       <prim-key-class>java.lang.Integer</prim-key-class>
>       <reentrant>true</reentrant>
>     </entity>
>   </enterprise-beans>
> </ejb-jar>
> {code}
> then NullPointerException is thrown
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.deployment.unit."entitybeanbmp.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."entitybeanbmp.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "entitybeanbmp.jar"                                      
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]                  
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]                           
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]                              
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]                                   
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]                                       
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]                                             
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011058: Failed to install component SimpleBMPBean                             
>   at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:102)                                
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]                  
>   ... 5 more
> Caused by: java.lang.NullPointerException                                                    
>   at org.jboss.as.ejb3.component.entity.EntityBeanObjectViewConfigurator$2.configureDependency(EntityBeanObjectViewConfigurator.java:108)                            
>   at org.jboss.as.ejb3.component.entity.EntityBeanObjectViewConfigurator$2.configureDependency(EntityBeanObjectViewConfigurator.java:105)                            
>   at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:139)                                   
>   at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:95)                                 
>   ... 6 more 
> {code}
> instead of some informative one.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5208) UT005023: Exception handling
 request: NullPointerException
In-Reply-To: <JIRA.12582646.1440586724000@Atlassian.JIRA>
References: <JIRA.12582646.1440586724000@Atlassian.JIRA>
	<JIRA.12582646.1440586724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582646.1440586724000.90347.1512581043171@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5208:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> UT005023: Exception handling request: NullPointerException
> ----------------------------------------------------------
>
>                 Key: WFLY-5208
>                 URL: https://issues.jboss.org/browse/WFLY-5208
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Michal Vinkler
>            Assignee: Stuart Douglas
>             Fix For: 10.0.0.Final
>
>
> Setup: 4-node cluster, one node at time either shuts down or undeploys application (clusterbench-ee7.ear), and then recovers after period of time, while standalone clients keep calling the application.
> This error was seen during clustering failover testing in the following scenarios:
> ejb-ejbservlet-shutdown-repl-async (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, failover type: server shutdown, with asynchronously replicated cache)
> ejb-ejbservlet-shutdown-repl-sync (the same as above, with synchronously replicated cache)
> ejb-ejbservlet-undeploy-dist-sync (failover type: application undeploy, with distributed cache which is replicated synchronously) 
> It occurs in these two situations (intermittently):
> 1. server startup after previous shutdown
> {code}
> [JBossINF] [0m[0m17:23:14,240 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started repl cache from web container
> [JBossINF] [0m[0m17:23:14,247 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 67) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> [JBossINF] [0m[0m17:23:14,374 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 66) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m17:23:14,375 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 66) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m17:23:15,708 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 65) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/clusterbench'
> [JBossINF] [0m[0m17:23:15,708 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/clusterbench-passivating'
> [JBossINF] [0m[0m17:23:16,784 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 71) WFLYUT0021: Registered web context: /clusterbench-passivating
> [JBossINF] [0m[0m17:23:17,198 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 65) WFLYUT0021: Registered web context: /clusterbench
> [JBossINF] [0m[31m17:23:18,931 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.NullPointerException
> [JBossINF] 	at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved(StatefulSessionObjectReferenceImpl.java:133)
> [JBossINF] 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:122)
> [JBossINF] 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> [JBossINF] 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> [JBossINF] 	at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_Weld$EnterpriseProxy$.getSerialAndIncrement(Unknown Source)
> [JBossINF] 	at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_WeldClientProxy.getSerialAndIncrement(Unknown Source)
> [JBossINF] 	at org.jboss.test.clusterbench.web.ejb.LocalEjbServlet.doGet(LocalEjbServlet.java:38)
> [JBossINF] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> [JBossINF] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> [JBossINF] 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> [JBossINF] 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> [JBossINF] 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> [JBossINF] 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> [JBossINF] 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> [JBossINF] 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> [JBossINF] 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> [JBossINF] 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> [JBossINF] 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> [JBossINF] 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> [JBossINF] 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> [JBossINF] 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbservlet-shutdown-repl-async/6/console-perf19/
> 2. Server shutdown/application undeploy
> {code}
> [JBossINF] [0m[0m18:04:35,977 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0211: Suspending server
> [JBossINF] [0m[0m18:04:35,981 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 2015/08/18 18:04:36:037 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - [SHUTDOWN] JBossShutdown command executed successfully.
> 2015/08/18 18:04:36:037 EDT [DEBUG][RMI TCP Connection(14)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Waiting for server to shutdown.
> [JBossINF] [0m[0m18:04:36,048 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 77) WFLYUT0022: Unregistered web context: /clusterbench-passivating
> [JBossINF] [0m[0m18:04:36,063 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 81) WFLYUT0022: Unregistered web context: /clusterbench
> [JBossINF] [0m[0m18:04:36,072 INFO  [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 82) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[31m18:04:36,106 ERROR [io.undertow.request] (default task-63) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.NullPointerException
> [JBossINF] 	at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved(StatefulSessionObjectReferenceImpl.java:133)
> [JBossINF] 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:122)
> [JBossINF] 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> [JBossINF] 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> [JBossINF] 	at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_Weld$EnterpriseProxy$.getSerialAndIncrement(Unknown Source)
> [JBossINF] 	at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_WeldClientProxy.getSerialAndIncrement(Unknown Source)
> [JBossINF] 	at org.jboss.test.clusterbench.web.ejb.LocalEjbServlet.doGet(LocalEjbServlet.java:38)
> [JBossINF] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> [JBossINF] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> [JBossINF] 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> [JBossINF] 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> [JBossINF] 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> [JBossINF] 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> [JBossINF] 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> [JBossINF] 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> [JBossINF] 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> [JBossINF] 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> [JBossINF] 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> [JBossINF] 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> [JBossINF] 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> [JBossINF] 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbservlet-shutdown-repl-sync/6/console-perf18/
> During server shutdown, it occurred also with different stacktrace:
> {code}
> [JBossINF] [0m[31m17:19:11,728 ERROR [io.undertow.request] (default task-128) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.NullPointerException
> [JBossINF] 	at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:143)
> [JBossINF] 	at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> [JBossINF] 
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbservlet-shutdown-repl-async/6/console-perf18/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2318) Access control exceptions
 missing for scoped roles
In-Reply-To: <JIRA.12503236.1381924408000@Atlassian.JIRA>
References: <JIRA.12503236.1381924408000@Atlassian.JIRA>
	<JIRA.12503236.1381924408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503236.1381924408000.90353.1512581043442@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2318:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Access control exceptions missing for scoped roles
> --------------------------------------------------
>
>                 Key: WFLY-2318
>                 URL: https://issues.jboss.org/browse/WFLY-2318
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.Final
>
>
> The following setup: user with two scoped roles assigned. maintainer for "main-servers", monitor for "other-servers". Requesting the access control meta data for the server group wildcard ]does not include "exceptions". 
> Expected result: the access control meta data response contains an "exception" for each server group (main-server-group & other-server-group)
> {code}
> [domain at localhost:9999 /] ./server-group=*:read-resource-description(access-control=trim-descriptions, operations=true){roles=main-servers, other-servers}
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [("server-group" => "*")],
>         "outcome" => "success",
>         "result" => {
>             "description" => undefined,
>             "attributes" => undefined,
>             "operations" => undefined,
>             "children" => {
>                 "deployment" => {"model-description" => undefined},
>                 "system-property" => {"model-description" => undefined},
>                 "jvm" => {"model-description" => undefined},
>                 "deployment-overlay" => {"model-description" => undefined}
>             },
>             "access-control" => {
>                 "default" => {
>                     "read" => true,
>                     "write" => true,
>                     "attributes" => {
>                         "socket-binding-port-offset" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "management-subsystem-endpoint" => {
>                             "read" => true,
>                             "write" => false
>                         },
>                         "socket-binding-group" => {
>                             "read" => true,
>                             "write" => true
>                         },
>                         "profile" => {
>                             "read" => true,
>                             "write" => true
>                         }
>                     },
>                     "operations" => {
>                         "read-children-names" => {"execute" => true},
>                         "read-operation-description" => {"execute" => true},
>                         "remove" => {"execute" => true},
>                         "read-resource-description" => {"execute" => true},
>                         "stop-servers" => {"execute" => true},
>                         "read-resource" => {"execute" => true},
>                         "add" => {"execute" => true},
>                         "read-attribute" => {"execute" => true},
>                         "whoami" => {"execute" => true},
>                         "read-children-types" => {"execute" => true},
>                         "read-operation-names" => {"execute" => true},
>                         "undefine-attribute" => {"execute" => true},
>                         "start-servers" => {"execute" => true},
>                         "read-children-resources" => {"execute" => true},
>                         "restart-servers" => {"execute" => true},
>                         "replace-deployment" => {"execute" => true},
>                         "write-attribute" => {"execute" => true}
>                     }
>                 },
>                 "exceptions" => {}
>             }
>         }
>     }]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4905) CacheRemoveHandler can't run
 in same op as remove of parent cache-container
In-Reply-To: <JIRA.12577760.1436655389000@Atlassian.JIRA>
References: <JIRA.12577760.1436655389000@Atlassian.JIRA>
	<JIRA.12577760.1436655389000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577760.1436655389000.90359.1512581043599@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4905:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> CacheRemoveHandler can't run in same op as remove of parent cache-container
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-4905
>                 URL: https://issues.jboss.org/browse/WFLY-4905
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 10.0.0.Final
>
>
> CacheRemoveHandler tries to read its parent resource in Stage.RUNTIME, which means it can't run in the same op (say a composite) with a remove of the parent, as the parent resource will be gone by RUNTIME.
> This will also interfere with the WFCORE-808 improvement.
> Easy fix, as the read of the parent resource looks to be cruft; the data is never used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1460) WildFly server fails to start
 with transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12493706.1370509487000@Atlassian.JIRA>
References: <JIRA.12493706.1370509487000@Atlassian.JIRA>
	<JIRA.12493706.1370509487000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493706.1370509487000.90370.1512581043977@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1460:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> WildFly server fails to start with transactions configured to be run with JDBCObject store
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1460
>                 URL: https://issues.jboss.org/browse/WFLY-1460
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ondra Chaloupka
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Final
>
>
> In case that you configure transactions subsystem for running with JDBCObject store the app server fails to start because of (it seems so) a circular dependency.
> You can expect the exception like:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 52) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "transactions")]): org.jboss.msc.service.CircularDependencyException: Container jboss-as has a circular dependency: [service jboss.txn.ArjunaObjectStoreEnvironment, service jboss.txn.ArjunaRecoveryManager, service jboss.connector.transactionintegration, service jboss.cached-connection-manager, service jboss.data-source.java:jboss/datasources/JDBCObjectDS] 
> {code}
> My assumption came from the configuration similar to this:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/JDBCObjectDS" pool-name="JDBCObjectDS" enabled="true" use-ccm="false"> 
> <connection-url>jdbc:postgresql://postgresserver.com:5432/user1</connection-url>
>   <driver-class>org.postgresql.Driver</driver-class>
>   <driver>postgresql-9.2-1002.jdbc4.jar</driver>
>   <security>
>     <user-name>user1</user-name>
>     <password>user1</password>
>   </security>
> </datasource> 
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/JDBCObjectDS" />
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2490) Connecting using
 https-remoting times out and leaves thread within CLI spinning at 100%
In-Reply-To: <JIRA.12524819.1384192055000@Atlassian.JIRA>
References: <JIRA.12524819.1384192055000@Atlassian.JIRA>
	<JIRA.12524819.1384192055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524819.1384192055000.90378.1512581044209@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2490:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2490
>                 URL: https://issues.jboss.org/browse/WFLY-2490
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: CLI, Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 10.0.0.Final
>
>
> HTTP Upgrade is not fully working when SSL is enabled, other tasks will address that but this issue is about the CLI connecting to a server where HTTP Upgrade is not possible - a thread within the CLI is left running at 100% even after connecting has timed out.
> {noformat}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {noformat}
> Connecting to the HTTP port where HTTP Upgrade is not available also results in a time out connecting rather than an early failure but does not result in the thread spinning at 100%
> {noformat}
> [disconnected /] connect http-remoting://localhost:9990
> The controller is not available at localhost:9990: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4850)
 ManagementClient.isServerInRunningState fails when server is stopped
In-Reply-To: <JIRA.12576715.1435740577000@Atlassian.JIRA>
References: <JIRA.12576715.1435740577000@Atlassian.JIRA>
	<JIRA.12576715.1435740577000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576715.1435740577000.90386.1512581044454@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4850:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> ManagementClient.isServerInRunningState fails when server is stopped
> --------------------------------------------------------------------
>
>                 Key: WFLY-4850
>                 URL: https://issues.jboss.org/browse/WFLY-4850
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Ondra Chaloupka
>            Assignee: James Perkins
>             Fix For: 10.0.0.Final
>
>
> Scenario: server is stopped (killed), working with arquillian to check if server is started or not
> Current implementation of the {{ManagementClient.isServerInRunningState}} catches only {{IOException}} (see [1]) and in such case false is returned. Otherwise exception is propagated upwards.
> That's a problem in case that assertions are enabled - which is true statement for wildfly testsuite (see pom.xml, surefire configuration and {{<enableAssertions>true</enableAssertions>}}). As state of the server is checked with assertions as well [2] then test fails on such assertion instead of getting false as server is stopped.
> In comparision with arquillian client for jboss-eap there is caught {{Throwable}} and returned false [3] which seems to me more correct.
> Could you, please, forwardport arquillian client behaviour from JBoss EAP to WildFly?
> [1] https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main/java/org/jboss/as/arquillian/container/ManagementClient.java#L197
> [2] https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/ActiveOperationSupport.java#L151
> [3] https://github.com/jbossas/jboss-eap/blob/6.x/arquillian/common/src/main/java/org/jboss/as/arquillian/container/ManagementClient.java#L177



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4961)
 CommandDispatcherFactory.getGroup().getNodes() returns empty list until 1st
 view change
In-Reply-To: <JIRA.12578498.1437167529000@Atlassian.JIRA>
References: <JIRA.12578498.1437167529000@Atlassian.JIRA>
	<JIRA.12578498.1437167529000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578498.1437167529000.90392.1512581044583@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4961:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> CommandDispatcherFactory.getGroup().getNodes() returns empty list until 1st view change
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-4961
>                 URL: https://issues.jboss.org/browse/WFLY-4961
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5142) JMS client which does not
 specify user/password during creating connection to server is not
 considered as "guest"
In-Reply-To: <JIRA.12581969.1440068214000@Atlassian.JIRA>
References: <JIRA.12581969.1440068214000@Atlassian.JIRA>
	<JIRA.12581969.1440068214000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581969.1440068214000.90399.1512581044782@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5142:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> JMS client which does not specify user/password during creating connection to server is not considered as "guest"
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5142
>                 URL: https://issues.jboss.org/browse/WFLY-5142
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation, JMS
>    Affects Versions: 10.0.0.Beta1
>         Environment: Fedora 22
> openjdk 8
>            Reporter: Erich Duda
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Final
>
>         Attachments: application-roles.properties, standalone-full-ha.xml
>
>
> Although remote calls requires to create an user and use explicit user credentials, in EAP 6 there is an workaround for that, see [JBPAPP6-1529|https://issues.jboss.org/browse/JBPAPP6-1529]. However, when I test the workaround in EAP 7, the JMS client is not considered as "guest" user.
> {noformat}
> javax.jms.JMSSecurityException: AMQ119031: Unable to validate user: null
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:410)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:335)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:262)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionChannel(ClientSessionFactoryImpl.java:1540)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:744)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:311)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:720)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:819)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:170)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:165)
> 	at org.jboss.qa.hornetq.test.security.SecurityClient.getConnection(SecurityClient.java:409)
> 	at org.jboss.qa.hornetq.test.security.SecurityClient.initializeClient(SecurityClient.java:114)
> 	at org.jboss.qa.hornetq.test.security.PermissionSecurityTestCase.testSecurityWithGuest(PermissionSecurityTestCase.java:123)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4357) Update the JDR Subsystem to
 Include a Type 4 UUID in its Report
In-Reply-To: <JIRA.12563397.1424186934000@Atlassian.JIRA>
References: <JIRA.12563397.1424186934000@Atlassian.JIRA>
	<JIRA.12563397.1424186934000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12563397.1424186934000.90405.1512581045014@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4357:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Update the JDR Subsystem to Include a Type 4 UUID in its Report
> ---------------------------------------------------------------
>
>                 Key: WFLY-4357
>                 URL: https://issues.jboss.org/browse/WFLY-4357
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JDR
>            Reporter: Keith Robertson
>            Assignee: Joshua Kinlaw
>             Fix For: 10.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4855) Test case for CXF-6469
 (schemaLocation in xsd import is not rewritten)
In-Reply-To: <JIRA.12576846.1435818207000@Atlassian.JIRA>
References: <JIRA.12576846.1435818207000@Atlassian.JIRA>
	<JIRA.12576846.1435818207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576846.1435818207000.90409.1512581045168@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4855:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Test case for CXF-6469 (schemaLocation in xsd import is not rewritten)
> ----------------------------------------------------------------------
>
>                 Key: WFLY-4855
>                 URL: https://issues.jboss.org/browse/WFLY-4855
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 10.0.0.Alpha4
>            Reporter: Tomas Hofman
>            Assignee: Tomas Hofman
>             Fix For: 10.0.0.Final
>
>
> Adding a test case for CXF-6469 - verifying the schema imports are rewritten in various situations.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5913) Add ability to specify
 external context on JNDI lookup binding
In-Reply-To: <JIRA.12597921.1451239297000@Atlassian.JIRA>
References: <JIRA.12597921.1451239297000@Atlassian.JIRA>
	<JIRA.12597921.1451239297000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597921.1451239297000.90413.1512581045258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5913:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Add ability to specify external context on JNDI lookup binding
> --------------------------------------------------------------
>
>                 Key: WFLY-5913
>                 URL: https://issues.jboss.org/browse/WFLY-5913
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>    Affects Versions: 10.0.0.CR5
>            Reporter: Guillermo Gonz?lez de Ag?ero
>             Fix For: 10.0.0.Final
>
>
> The Naming subsystem allows to create alias to JNDI lookups on the local context, and also allows to bind an external context to an entry. However, it isn't possible to bind a lookup to an external context.
> My personal use case is that I have an exported JMS Topic on a Remote WildFly. I'd like to be able to use it from my application like if it where local.
> For now, I've created an Object Factory that lookups the external context and then lookups the topic.
> An attribute indicating the context could be added. If none specified, local context should be used. Something like this:
> {code:xml}
> <bindings>
>     <external-context name="java:/global/mqserver" module="org.jboss.as.naming" class="javax.naming.InitialContext" cache="true">
>         <environment>
>             <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
>             <property name="java.naming.provider.url" value="http-remoting://localhost:8290"/>
>             <property name="java.naming.security.principal" value="remote"/>
>             <property name="java.naming.security.credentials" value="remote"/>
>         </environment>
>     </external-context>
>     <lookup name="java:/jms/topic/ImportedTopic" lookup="java:/jms/topic/MyTopic" externalContext="java:/global/mqserver"/>
> </bindings>
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:24:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5228) Tests for schemaLocation
 rewrites in xsd import (CXF-6469) in incorrect location
In-Reply-To: <JIRA.12583121.1440764373000@Atlassian.JIRA>
References: <JIRA.12583121.1440764373000@Atlassian.JIRA>
	<JIRA.12583121.1440764373000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583121.1440764373000.90419.1512581045650@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5228:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Tests for schemaLocation rewrites in xsd import (CXF-6469) in incorrect location
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-5228
>                 URL: https://issues.jboss.org/browse/WFLY-5228
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Rostislav Svoboda
>            Assignee: Tomas Hofman
>             Fix For: 10.0.0.Final
>
>
> WS tests moved to separate module.
> Schemalocations tests in https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/ws are incorrectly located.
> They should be moved to https://github.com/wildfly/wildfly/tree/master/testsuite/integration/ws



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4661) Provide Support for Clustered
 Singleton MDBs
In-Reply-To: <JIRA.12572440.1432247552000@Atlassian.JIRA>
References: <JIRA.12572440.1432247552000@Atlassian.JIRA>
	<JIRA.12572440.1432247552000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572440.1432247552000.90428.1512581045922@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4661:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Provide Support for Clustered Singleton MDBs
> --------------------------------------------
>
>                 Key: WFLY-4661
>                 URL: https://issues.jboss.org/browse/WFLY-4661
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, JMS
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> Provide Support for Clustered Singleton MDBs.
> Provide annotation and configuration support to mark such MDB deployments Clustered Singleton MDBs.
> When "Clustered Singleton MDBs" are deployed in a cluster; only one node (server) is active to consume messages serially. When the node fails; another the active node's "Clustered Singleton MDBs" starts consuming the messages.
> To mark an MDB as clustered singleton, one can either use the clustered-singleton xml element, like this:
> <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
>                xmlns="http://java.sun.com/xml/ns/javaee"
>                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>                xmlns:c="urn:clustering:1.1"
>                xmlns:d="urn:delivery-active:1.1"
>                xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
>                version="3.1"
>                impl-version="2.0">
>        <c:clustering>
>             <ejb-name>HelloWorldQueueMDB</ejb-name>
>             <c:clustered-singleton>true</c:clustered-singleton>
>         </c:clustering>
> </jboss:ejb-jar>
> Or one can use the @org.jboss.ejb3.annotation.ClusteredSingleton in your MDB class.
> This feature requires no extra configuration at the server, apart from running the service in a cluster.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5334) Update to HAL 2.8.9.Final
In-Reply-To: <JIRA.12584816.1442235373000@Atlassian.JIRA>
References: <JIRA.12584816.1442235373000@Atlassian.JIRA>
	<JIRA.12584816.1442235373000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584816.1442235373000.90432.1512581046002@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5334:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Update to HAL 2.8.9.Final
> -------------------------
>
>                 Key: WFLY-5334
>                 URL: https://issues.jboss.org/browse/WFLY-5334
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 10.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5517) Tests from RTS module fails
 with security manager
In-Reply-To: <JIRA.12588779.1444662730000@Atlassian.JIRA>
References: <JIRA.12588779.1444662730000@Atlassian.JIRA>
	<JIRA.12588779.1444662730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588779.1444662730000.90437.1512581046136@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5517:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Tests from RTS module fails with security manager
> -------------------------------------------------
>
>                 Key: WFLY-5517
>                 URL: https://issues.jboss.org/browse/WFLY-5517
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.CR2
>            Reporter: Marek Kopeck?
>            Assignee: Gytis Trikleris
>             Fix For: 10.0.0.Final
>
>         Attachments: rts.module.txt
>
>
> *Description of problem:*
> Tests from RTS module fails with security manager
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./integration-tests.sh -Dmaven.repo.local=$MAVEN_REPO_LOCAL -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Djboss.dist=$JBOSS_DIST -Dsecurity.manager -Dts.rts
> *Actual results:*
> See attached file
> *Expected results:*
> No errors



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:24:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5528) "WFLYCTL0171: unsatisfied
 dependencies" when removing a modified XA datasource
In-Reply-To: <JIRA.12589113.1444833898000@Atlassian.JIRA>
References: <JIRA.12589113.1444833898000@Atlassian.JIRA>
	<JIRA.12589113.1444833898000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589113.1444833898000.90442.1512581046342@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5528:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> "WFLYCTL0171: unsatisfied dependencies" when removing a modified XA datasource
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-5528
>                 URL: https://issues.jboss.org/browse/WFLY-5528
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 9.0.1.Final, 10.0.0.CR2
>            Reporter: Peter Palaga
>            Assignee: Stefano Maestri
>            Priority: Critical
>             Fix For: 10.0.0.Final
>
>
> Please note that the present scenario ends with a similar error message and has the same workaround as WFLY-5527.
> Steps to reproduce:
> (1) Create an XA Datasource:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "add",
>             "address" => [
>                 ("subsystem" => "datasources"),
>                 ("xa-data-source" => "testXaDs")
>             ],
>             "jndi-name" => "java:/testXaDs",
>             "driver-name" => "h2",
>             "xa-datasource-class" => "org.h2.jdbcx.JdbcDataSource",
>             "user-name" => "sa",
>             "password" => "sa",
>             "new-connection-sql" => undefined,
>             "url-delimiter" => undefined,
>             "url-selector-strategy-class-name" => undefined,
>             "use-java-context" => undefined,
>             "max-pool-size" => undefined,
>             "min-pool-size" => undefined,
>             "initial-pool-size" => undefined,
>             "pool-prefill" => undefined,
>             "pool-use-strict-min" => undefined,
>             "interleaving" => undefined,
>             "capacity-incrementer-class" => undefined,
>             "capacity-decrementer-class" => undefined,
>             "no-tx-separate-pool" => undefined,
>             "pad-xid" => undefined,
>             "same-rm-override" => undefined,
>             "wrap-xa-resource" => undefined,
>             "security-domain" => undefined,
>             "reauth-plugin-class-name" => undefined,
>             "flush-strategy" => undefined,
>             "allow-multiple-users" => undefined,
>             "connection-listener-class" => undefined,
>             "prepared-statements-cache-size" => undefined,
>             "share-prepared-statements" => undefined,
>             "track-statements" => undefined,
>             "allocation-retry" => undefined,
>             "allocation-retry-wait-millis" => undefined,
>             "blocking-timeout-wait-millis" => undefined,
>             "idle-timeout-minutes" => undefined,
>             "query-timeout" => undefined,
>             "use-try-lock" => undefined,
>             "set-tx-query-timeout" => undefined,
>             "transaction-isolation" => undefined,
>             "check-valid-connection-sql" => undefined,
>             "exception-sorter-class-name" => undefined,
>             "stale-connection-checker-class-name" => undefined,
>             "valid-connection-checker-class-name" => undefined,
>             "background-validation-millis" => undefined,
>             "background-validation" => undefined,
>             "use-fast-fail" => undefined,
>             "validate-on-match" => undefined,
>             "xa-resource-timeout" => undefined,
>             "spy" => undefined,
>             "use-ccm" => undefined,
>             "enabled" => undefined,
>             "connectable" => undefined,
>             "statistics-enabled" => undefined,
>             "tracking" => undefined,
>             "recovery-username" => undefined,
>             "recovery-password" => undefined,
>             "recovery-security-domain" => undefined,
>             "recovery-plugin-class-name" => undefined,
>             "no-recovery" => undefined,
>             "url-property" => undefined,
>             "reauth-plugin-properties" => undefined,
>             "exception-sorter-properties" => undefined,
>             "stale-connection-checker-properties" => undefined,
>             "valid-connection-checker-properties" => undefined,
>             "recovery-plugin-properties" => undefined,
>             "connection-listener-property" => undefined,
>             "capacity-incrementer-properties" => undefined,
>             "capacity-decrementer-properties" => undefined
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("subsystem" => "datasources"),
>                 ("xa-data-source" => "testXaDs"),
>                 ("xa-datasource-properties" => "URL")
>             ],
>             "value" => "jdbc:h2:mem:test"
>         }
>     ]
> }
> {code}
> (2) Update its {{"jndi-name"}}
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "write-attribute",
>             "address" => [
>                 ("subsystem" => "datasources"),
>                 ("xa-data-source" => "testXaDs")
>             ],
>             "name" => "jndi-name",
>             "value" => "java:/testXaDs_changed"
>         }
>     ]
> }
> {code}
> This composite operation succeeds.
> (3) Remove the XA Datasource:
> {code}
> {
>     "operation" => "remove",
>     "address" => [
>         ("subsystem" => "datasources"),
>         ("xa-data-source" => "testXaDs")
>     ]
> }
> {code}
> NOT OK: the operation fails: 
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.data-source.reference-factory.testXaDs was depended upon by service jboss.naming.context.java.testXaDs
> Service jboss.xa-data-source-config.testXaDs was depended upon by service jboss.data-source.java:/testXaDs",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> EXPECTED: the operation should succeed
> Workaround: When the same request is sent once again, the second invocation succeeds.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5083) [Migration operation]
 group-address/group-port/local-bind-address/local-bind-port in
 broadcast-group are not migrated
In-Reply-To: <JIRA.12580955.1439376398000@Atlassian.JIRA>
References: <JIRA.12580955.1439376398000@Atlassian.JIRA>
	<JIRA.12580955.1439376398000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580955.1439376398000.90448.1512581046475@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5083:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> [Migration operation] group-address/group-port/local-bind-address/local-bind-port in broadcast-group are not migrated
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5083
>                 URL: https://issues.jboss.org/browse/WFLY-5083
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Final
>
>
> If broadcast group with local-bind-address,local-bind-port, group-address and group-port then those parameters are not migrated properly:
> For example HornetQ configuration:
> {code}
>  <broadcast-group name="groupA">
>                 <local-bind-address>localhost</local-bind-address>
>                 <local-bind-port>12345</local-bind-port>
>                 <group-address>224.0.1.105</group-address>
>                 <group-port>23456</group-port>
>                 <broadcast-period>${broadcast.period:2500}</broadcast-period>
>                 <connector-ref>netty</connector-ref>
>                 <connector-ref>netty-throughput</connector-ref>
>             </broadcast-group>
> {code}
> is migrated to Artemis like:
> {code}
>                 <broadcast-group name="groupA" connectors="netty netty-throughput" broadcast-period="${broadcast.period:2500}"/>
> {code}
> With such a configuration server cannot be started. There is no warning pointing to this problem.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5030) Intermittent failure of
 deployment containing two datasources in -ds.xml
In-Reply-To: <JIRA.12579806.1438191076000@Atlassian.JIRA>
References: <JIRA.12579806.1438191076000@Atlassian.JIRA>
	<JIRA.12579806.1438191076000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579806.1438191076000.90454.1512581046624@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5030:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Intermittent failure of deployment containing two datasources in -ds.xml
> ------------------------------------------------------------------------
>
>                 Key: WFLY-5030
>                 URL: https://issues.jboss.org/browse/WFLY-5030
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Jan Bliz??k
>            Assignee: Stefano Maestri
>             Fix For: 10.0.0.Final
>
>         Attachments: one-datasource.jar, two-datasources.jar
>
>
> Running smoke runs of JBossWS in EAP7, I occasionally hit test failure of WSRMStoreFeatureTestCase (from JBossWS testsuite). The testcase uses deployment that should add some datasources, but deploying ends up with:
> {code}
> org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/rmclientdb.statistics: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 	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.IllegalArgumentException: WFLYCTL0218: A node is already registered at '/deployment=*/subsystem=datasources/data-source=*/statistics=jdbc'
> 	at org.jboss.as.controller.registry.NodeSubregistry.register(NodeSubregistry.java:86)
> 	at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:180)
> 	at org.jboss.as.connector.services.datasources.statistics.DataSourceStatisticsService.start(DataSourceStatisticsService.java:85)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	... 3 more
> {code}
> After some debugging, the problematic scenario seems to be:
> 1) there is a deployment (jar/war, doesn't matter) containing -ds.xml configuration file
> 2) this file contains definition of at least two datasources to be added



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:24:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5134) Error creating Batch JDBC
 storage in domain
In-Reply-To: <JIRA.12581816.1439979236000@Atlassian.JIRA>
References: <JIRA.12581816.1439979236000@Atlassian.JIRA>
	<JIRA.12581816.1439979236000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581816.1439979236000.90461.1512581046868@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5134:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Error creating Batch JDBC storage in domain
> -------------------------------------------
>
>                 Key: WFLY-5134
>                 URL: https://issues.jboss.org/browse/WFLY-5134
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 10.0.0.Beta1
>         Environment: Oracle, DB2, Derby, Sybase, Firebird, and SQL Server databases
>            Reporter: Jan Martiska
>            Assignee: Cheng Fang
>             Fix For: 10.0.0.Final
>
>
> When multiple servers (eg. a server-group in a JBoss domain) attempt to create a JDBC Batch repository at once, and they share a common database, they race in creating the database tables, because sometimes instance A will create the table PARTITION_EXECUTION after instance B invokes the check whether this table exists (this check is used to decide whether all tables need to be created) - therefore B will decide to create all tables too.
> If the database doesn't support the IF NOT EXISTS clause in CREATE TABLE (db2, oracle, sybase..), it will probably lead to a failure like 'table already exists', which in turn rolls back the creation of the JDBC store on all nodes in the domain, including those where the schema creation succeeded or was skipped. The tables remain physically in the database.
> This is similar to WFLY-5061, but this time, it is caused by having multiple servers in a domain.
> Sharing a common database in domain mode should work because it is useful for restarting failed jobs on different nodes if one node crashes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4756) jboss-ejb-iiop_1.0.xsd Should
 be removed from EAP code base and moved to metadata project
In-Reply-To: <JIRA.12574191.1433768058000@Atlassian.JIRA>
References: <JIRA.12574191.1433768058000@Atlassian.JIRA>
	<JIRA.12574191.1433768058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574191.1433768058000.90468.1512581047086@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4756:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> jboss-ejb-iiop_1.0.xsd Should be removed from EAP code base and moved to metadata project
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-4756
>                 URL: https://issues.jboss.org/browse/WFLY-4756
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, IIOP
>    Affects Versions: 10.0.0.Alpha2
>         Environment: EAP default installations
>            Reporter: Weston Price
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.Final
>
>
> Currently the jboss-ejb-iiop_1.0.xsd file resides in the EAP project under:
> /Users/wmprice/projects/javaprojects/jboss-eap/ejb3/src/main/resources
> directory. The correct place for this file should be in the metadata project where the IIOPMetaDataParser and MetaData reside.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5387) Upgrade Narayana to
	5.2.4.Final
In-Reply-To: <JIRA.12585731.1442988528000@Atlassian.JIRA>
References: <JIRA.12585731.1442988528000@Atlassian.JIRA>
	<JIRA.12585731.1442988528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585731.1442988528000.90474.1512581047277@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5387:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Upgrade Narayana to 5.2.4.Final
> -------------------------------
>
>                 Key: WFLY-5387
>                 URL: https://issues.jboss.org/browse/WFLY-5387
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>    Affects Versions: 10.0.0.CR1
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 10.0.0.Final
>
>
> Includes miscellaneous bug fixes 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5176) Some tests end with Security
 Exception after login with security manager
In-Reply-To: <JIRA.12582274.1440403886000@Atlassian.JIRA>
References: <JIRA.12582274.1440403886000@Atlassian.JIRA>
	<JIRA.12582274.1440403886000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582274.1440403886000.90481.1512581047421@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5176:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Some tests end with Security Exception after login with security manager
> ------------------------------------------------------------------------
>
>                 Key: WFLY-5176
>                 URL: https://issues.jboss.org/browse/WFLY-5176
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Ondrej Kotek
>             Fix For: 10.0.0.Final
>
>
> *Description of problem:*
> Some tests end with Security Exception after login with security manager. 
> *Affected tests found so far:*
> * org.jboss.as.test.integration.ejb.security.AnnotationAuthorizationTestCase
> * org.jboss.as.test.integration.ejb.security.AuthenticationTestCase
> * org.jboss.as.test.integration.ejb.security.EJBInWarDefaultSecurityDomainTestCase#testSecurityOnBeanInAbsenceOfExplicitSecurityDomain
> * org.jboss.as.test.integration.ejb.security.LifecycleTestCase
> * org.jboss.as.test.integration.ejb.security.SecurityDDOverrideTestCase#testDDOverride
> * org.jboss.as.test.integration.ejb.security.asynchronous.AsynchronousSecurityTestCase
> * org.jboss.as.test.integration.ejb.security.missingmethodpermission.MissingMethodPermissionsDefaultAllowedTestCase
> * org.jboss.as.test.integration.ejb.security.missingmethodpermission.MissingMethodPermissionsTestCase
> * org.jboss.as.test.integration.ejb.security.rolelink.SecurityRoleLinkTestCase#testIsCallerInRole
> * org.jboss.as.test.integration.ejb.security.runas.RunAsTestCase
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2  -DfailIfNoTests=false  -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=AnnotationAuthorizationTestCase
> *Actual results:*
> {noformat}
> javax.security.auth.login.LoginException: Security Exception
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:841)
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:588)
> 	at org.jboss.as.test.integration.ejb.security.AnnotationAuthorizationTestCase.testRolesAllowedOverriden_User2(AnnotationAuthorizationTestCase.java:187)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:24:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4960) Discard interceptors during
 messaging migration
In-Reply-To: <JIRA.12578436.1437139915000@Atlassian.JIRA>
References: <JIRA.12578436.1437139915000@Atlassian.JIRA>
	<JIRA.12578436.1437139915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578436.1437139915000.90487.1512581047582@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4960:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Discard interceptors during messaging migration
> -----------------------------------------------
>
>                 Key: WFLY-4960
>                 URL: https://issues.jboss.org/browse/WFLY-4960
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Final
>
>
> the messaging subsystem :migrate operation must discard any incoming or outgoing interceptors that are defined for hornetq-server resources.
> The base type of interceptors have changed in Artemis (at least their packages) and HornetQ-based interceptors will not be loaded by Artemis.
> Discard them during the :migrate operation with a warning that their base type must be changed and they must be provided in their own module (once WFLY-4867 is done)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5183)
 VaultSystemPropertyOnServerStartTestCase ends with "Internal Server Error"
 with security manager
In-Reply-To: <JIRA.12582320.1440418843000@Atlassian.JIRA>
References: <JIRA.12582320.1440418843000@Atlassian.JIRA>
	<JIRA.12582320.1440418843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582320.1440418843000.90493.1512581047915@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5183:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> VaultSystemPropertyOnServerStartTestCase ends with "Internal Server Error" with security manager
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5183
>                 URL: https://issues.jboss.org/browse/WFLY-5183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Ondrej Kotek
>             Fix For: 10.0.0.Final
>
>
> *Description of problem:*
> VaultSystemPropertyOnServerStartTestCase ends with "Internal Server Error" with security manager
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2  -DfailIfNoTests=false  -Dsecurity.manager -Dts.noSmoke -Dts.manualmode -Dtest=VaultSystemPropertyOnServerStartTestCase
> *Actual results:*
> {noformat}
> java.util.concurrent.ExecutionException: java.io.IOException: HTTP Status 500 Response: <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: HTTP Status 500 Response: <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> 	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> 	at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> 	at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:51)
> 	at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:81)
> 	at org.jboss.as.test.manualmode.security.VaultSystemPropertyOnServerStartTestCase.testVaultedSystemPropertyOnStart(VaultSystemPropertyOnServerStartTestCase.java:94)
> Caused by: java.io.IOException: HTTP Status 500 Response: <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> 	at org.jboss.as.test.integration.common.HttpRequest.processResponse(HttpRequest.java:156)
> 	at org.jboss.as.test.integration.common.HttpRequest.access$000(HttpRequest.java:45)
> 	at org.jboss.as.test.integration.common.HttpRequest$1.call(HttpRequest.java:78)
> 	at org.jboss.as.test.integration.common.HttpRequest$1.call(HttpRequest.java:73)
> 	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:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:24:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5003) AuthenticationTestCase fails
 was bind address is changed by -Dnode0 property
In-Reply-To: <JIRA.12579267.1437724756000@Atlassian.JIRA>
References: <JIRA.12579267.1437724756000@Atlassian.JIRA>
	<JIRA.12579267.1437724756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579267.1437724756000.90499.1512581048412@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5003:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> AuthenticationTestCase fails was bind address is changed by -Dnode0 property
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5003
>                 URL: https://issues.jboss.org/browse/WFLY-5003
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.Alpha5
>            Reporter: Petr Kremensky
>            Assignee: Jan Martiska
>             Fix For: 10.0.0.Final
>
>
> org.jboss.as.test.integration.ejb.security.AuthenticationTestCase fails once -Dnode0 is used. On the first sight, *managementClient.getWebUri()* seems to be one to blame as "http://localhost:8080" is always used now.
> {noformat}
> Running org.jboss.as.test.integration.ejb.security.AuthenticationTestCase
> Tests run: 19, Failures: 1, Errors: 8, Skipped: 0, Time elapsed: 1.127 sec <<< FAILURE! - in org.jboss.as.test.integration.ejb.security.AuthenticationTestCase
> testAuthentication_ReAuth_ViaServlet(org.jboss.as.test.integration.ejb.security.AuthenticationTestCase)  Time elapsed: 0.126 sec  <<< ERROR!
> java.io.IOException: java.util.concurrent.ExecutionException: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	at java.net.Socket.connect(Socket.java:538)
> 	at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1168)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1104)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:998)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:932)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1512)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440)
> 	at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
> 	at org.jboss.as.test.integration.ejb.security.AuthenticationTestCase.processResponse(AuthenticationTestCase.java:335)
> 	at org.jboss.as.test.integration.ejb.security.AuthenticationTestCase.access$000(AuthenticationTestCase.java:79)
> testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet(org.jboss.as.test.integration.ejb.security.AuthenticationTestCase)  Time elapsed: 0.046 sec  <<< FAILURE!
> java.lang.AssertionError: null
> 	at org.junit.Assert.fail(Assert.java:86)
> 	at org.junit.Assert.assertTrue(Assert.java:41)
> 	at org.junit.Assert.assertTrue(Assert.java:52)
> 	at org.jboss.as.test.integration.ejb.security.AuthenticationTestCase.testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet(AuthenticationTestCase.java:260)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4922) Add smoke test for
 <deny-uncovered-http-methods/> tag
In-Reply-To: <JIRA.12577941.1436857811000@Atlassian.JIRA>
References: <JIRA.12577941.1436857811000@Atlassian.JIRA>
	<JIRA.12577941.1436857811000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577941.1436857811000.90503.1512581048687@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4922:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Add smoke test for <deny-uncovered-http-methods/> tag
> -----------------------------------------------------
>
>                 Key: WFLY-4922
>                 URL: https://issues.jboss.org/browse/WFLY-4922
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Jan Tymel
>             Fix For: 10.0.0.Final
>
>
> With Java Servlet 3.1 specification [1] comes possibility to use <deny-uncovered-http-methods/> tag in web.xml file. This new feature should be tested by a basic smoke test in WildFly testsuite.
> Brief description of test case:
> * set some of HTTP methods secured
> * verify that these methods are accessible
> * when anyone tries to use other than specified (i.e. secured) HTTP methods, status code 403 should be returned (according to specification)
> [1] https://jcp.org/en/jsr/detail?id=340



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5527) "WFLYCTL0171 unsatisfied
 dependencies" when removing an xa-datasource-properties resource
In-Reply-To: <JIRA.12589086.1444829818000@Atlassian.JIRA>
References: <JIRA.12589086.1444829818000@Atlassian.JIRA>
	<JIRA.12589086.1444829818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589086.1444829818000.90509.1512581048877@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5527:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> "WFLYCTL0171 unsatisfied dependencies" when removing an xa-datasource-properties resource
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5527
>                 URL: https://issues.jboss.org/browse/WFLY-5527
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 9.0.1.Final, 10.0.0.CR2
>            Reporter: Peter Palaga
>            Assignee: Stefano Maestri
>            Priority: Critical
>             Fix For: 10.0.0.Final
>
>
> Steps to reproduce, same fro WF 9.0.1.Final and 10.0.0.CR2:
> (1) create an XA Datasource:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "add",
>             "address" => [
>                 ("subsystem" => "datasources"),
>                 ("xa-data-source" => "testXaDs")
>             ],
>             "jndi-name" => "java:/testXaDs",
>             "driver-name" => "h2",
>             "xa-datasource-class" => "org.h2.jdbcx.JdbcDataSource",
>             "user-name" => "sa",
>             "password" => "sa",
>             "new-connection-sql" => undefined,
>             "url-delimiter" => undefined,
>             "url-selector-strategy-class-name" => undefined,
>             "use-java-context" => undefined,
>             "max-pool-size" => undefined,
>             "min-pool-size" => undefined,
>             "initial-pool-size" => undefined,
>             "pool-prefill" => undefined,
>             "pool-use-strict-min" => undefined,
>             "interleaving" => undefined,
>             "capacity-incrementer-class" => undefined,
>             "capacity-decrementer-class" => undefined,
>             "no-tx-separate-pool" => undefined,
>             "pad-xid" => undefined,
>             "same-rm-override" => undefined,
>             "wrap-xa-resource" => undefined,
>             "security-domain" => undefined,
>             "reauth-plugin-class-name" => undefined,
>             "flush-strategy" => undefined,
>             "allow-multiple-users" => undefined,
>             "connection-listener-class" => undefined,
>             "prepared-statements-cache-size" => undefined,
>             "share-prepared-statements" => undefined,
>             "track-statements" => undefined,
>             "allocation-retry" => undefined,
>             "allocation-retry-wait-millis" => undefined,
>             "blocking-timeout-wait-millis" => undefined,
>             "idle-timeout-minutes" => undefined,
>             "query-timeout" => undefined,
>             "use-try-lock" => undefined,
>             "set-tx-query-timeout" => undefined,
>             "transaction-isolation" => undefined,
>             "check-valid-connection-sql" => undefined,
>             "exception-sorter-class-name" => undefined,
>             "stale-connection-checker-class-name" => undefined,
>             "valid-connection-checker-class-name" => undefined,
>             "background-validation-millis" => undefined,
>             "background-validation" => undefined,
>             "use-fast-fail" => undefined,
>             "validate-on-match" => undefined,
>             "xa-resource-timeout" => undefined,
>             "spy" => undefined,
>             "use-ccm" => undefined,
>             "enabled" => undefined,
>             "connectable" => undefined,
>             "statistics-enabled" => undefined,
>             "tracking" => undefined,
>             "recovery-username" => undefined,
>             "recovery-password" => undefined,
>             "recovery-security-domain" => undefined,
>             "recovery-plugin-class-name" => undefined,
>             "no-recovery" => undefined,
>             "url-property" => undefined,
>             "reauth-plugin-properties" => undefined,
>             "exception-sorter-properties" => undefined,
>             "stale-connection-checker-properties" => undefined,
>             "valid-connection-checker-properties" => undefined,
>             "recovery-plugin-properties" => undefined,
>             "connection-listener-property" => undefined,
>             "capacity-incrementer-properties" => undefined,
>             "capacity-decrementer-properties" => undefined
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("subsystem" => "datasources"),
>                 ("xa-data-source" => "testXaDs"),
>                 ("xa-datasource-properties" => "URL")
>             ],
>             "value" => "jdbc:h2:mem:test"
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("subsystem" => "datasources"),
>                 ("xa-data-source" => "testXaDs"),
>                 ("xa-datasource-properties" => "xaProp2")
>             ],
>             "value" => "xaVal2"
>         }
>     ]
> }
> {code}
> (2) Update or remove any of the {{xa-datasource-properties}}:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "remove",
>             "address" => [
>                 ("subsystem" => "datasources"),
>                 ("xa-data-source" => "testXaDs"),
>                 ("xa-datasource-properties" => "URL")
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("subsystem" => "datasources"),
>                 ("xa-data-source" => "testXaDs"),
>                 ("xa-datasource-properties" => "URL")
>             ],
>             "value" => "jdbc:h2:mem:test;DB_CLOSE_DELAY=5000"
>         },
>         {
>             "operation" => "remove",
>             "address" => [
>                 ("subsystem" => "datasources"),
>                 ("xa-data-source" => "testXaDs"),
>                 ("xa-datasource-properties" => "xaProp2")
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("subsystem" => "datasources"),
>                 ("xa-data-source" => "testXaDs"),
>                 ("xa-datasource-properties" => "xaProp3")
>             ],
>             "value" => "xaVal3"
>         }
>     ]
> }
> {code}
> (3) NOT OK: the composite operation fails
> {code}
> {
>     "outcome" => "failed",
>     "result" => {
>         "step-1" => {
>             "outcome" => "failed",
>             "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.xa-data-source-config.testXaDs.xa-datasource-properties.URL was depended upon by service jboss.xa-data-source-config.testXaDs",
>             "rolled-back" => true
>         },
>         "step-2" => {
>             "outcome" => "failed",
>             "response-headers" => {"operation-requires-reload" => true},
>             "rolled-back" => true
>         },
>         "step-3" => {
>             "outcome" => "failed",
>             "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.xa-data-source-config.testXaDs.xa-datasource-properties.xaProp2 was depended upon by service jboss.xa-data-source-config.testXaDs",
>             "rolled-back" => true
>         },
>         "step-4" => {
>             "outcome" => "failed",
>             "response-headers" => {"operation-requires-reload" => true},
>             "rolled-back" => true
>         }
>     },
>     "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
>         "Operation step-7" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.xa-data-source-config.testXaDs.xa-datasource-properties.URL was depended upon by service jboss.xa-data-source-config.testXaDs",
>         "Operation step-9" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.xa-data-source-config.testXaDs.xa-datasource-properties.xaProp2 was depended upon by service jboss.xa-data-source-config.testXaDs"
>     }},
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> EXPECTED: the operation should succeed
> Workaround: When the same request is sent once again, the second invocation succeeds.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5309) jsf/richfaces problem on
	wildfly
In-Reply-To: <JIRA.12584401.1441802956000@Atlassian.JIRA>
References: <JIRA.12584401.1441802956000@Atlassian.JIRA>
	<JIRA.12584401.1441802956000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584401.1441802956000.90516.1512581049072@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5309:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> jsf/richfaces problem on wildfly 
> ---------------------------------
>
>                 Key: WFLY-5309
>                 URL: https://issues.jboss.org/browse/WFLY-5309
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 9.0.1.Final
>            Reporter: Ja kub
>            Assignee: Dmitrii Tikhomirov
>             Fix For: 10.0.0.Final
>
>         Attachments: pom.xml, wildfly-test-RF-4.5.8.tar.gz, wildfly-test.rar
>
>
> attached application with
> <jsf.version>2.2.2</jsf.version>
> <org.richfaces.version>4.3.7.Final</org.richfaces.version>
> works fine on wildfly 8.0, on above versions there is a stacktracee,
> now I have tested on 9.0.1 with following result:
> 14:29:38,973 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) started in 48493ms - Started 888 of 1068 services (221 services are lazy, passive or on-demand)
> 14:29:43,690 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /webshop/acme.xhtml: java.lang.IllegalStateException
>         at com.sun.faces.context.FacesContextImpl.assertNotReleased(FacesContextImpl.java:712)
>         at com.sun.faces.context.FacesContextImpl.getAttributes(FacesContextImpl.java:239)
>         at org.richfaces.context.ExtendedPartialViewContext.setInstance(ExtendedPartialViewContext.java:55)
>         at org.richfaces.context.ExtendedPartialViewContext.release(ExtendedPartialViewContext.java:64)
>         at org.richfaces.context.ExtendedPartialViewContextImpl.release(ExtendedPartialViewContextImpl.java:424)
>         at com.sun.faces.context.FacesContextImpl.release(FacesContextImpl.java:598)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:673)
>         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>         at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:164)
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>         at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118)
>         at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:103)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:154)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:45)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:199)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:110)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:50)
>         at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>         at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>         at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>         at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>         at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344)
>         at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261)
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>         at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:202)
>         at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:180)
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>         at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
>         at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>         at org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:176)
>         at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>         at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>         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:282)
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>         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(ThreadPoolExecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         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 Dec  6 12:24:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4972) EjbAppDsRemoveTestCase fails
 intermittently
In-Reply-To: <JIRA.12578678.1437452211000@Atlassian.JIRA>
References: <JIRA.12578678.1437452211000@Atlassian.JIRA>
	<JIRA.12578678.1437452211000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578678.1437452211000.90521.1512581049203@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4972:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> EjbAppDsRemoveTestCase fails intermittently
> -------------------------------------------
>
>                 Key: WFLY-4972
>                 URL: https://issues.jboss.org/browse/WFLY-4972
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Stuart Douglas
>            Assignee: Ivo Studensky
>             Fix For: 10.0.0.Final
>
>
> See http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=61462&tab=buildResultsDiv&buildTypeId=WF_MasterLinux
> It looks like the deployment is not coming back up after the datasource has been removed. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4794) Add logging deployment
 resource tests for a WAR and EAR deployment
In-Reply-To: <JIRA.12575236.1434495058000@Atlassian.JIRA>
References: <JIRA.12575236.1434495058000@Atlassian.JIRA>
	<JIRA.12575236.1434495058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575236.1434495058000.90526.1512581049341@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4794:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Add logging deployment resource tests for a WAR and EAR deployment
> ------------------------------------------------------------------
>
>                 Key: WFLY-4794
>                 URL: https://issues.jboss.org/browse/WFLY-4794
>             Project: WildFly
>          Issue Type: Task
>          Components: Logging, Test Suite
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 10.0.0.Final
>
>
> WildFly Core can only reliably test JAR deployments for logging configurations. Tests should be added to ensure WAR's and EAR's work as expected.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4647)
 RemoteOutboundConnectionReconnectTestCase,
 EJBClientReconnectionTestCase configured as clustered test cases
In-Reply-To: <JIRA.12572259.1432134008000@Atlassian.JIRA>
References: <JIRA.12572259.1432134008000@Atlassian.JIRA>
	<JIRA.12572259.1432134008000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572259.1432134008000.90532.1512581049486@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4647:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> RemoteOutboundConnectionReconnectTestCase, EJBClientReconnectionTestCase configured as clustered test cases
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4647
>                 URL: https://issues.jboss.org/browse/WFLY-4647
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Michal Vinkler
>             Fix For: 10.0.0.Final
>
>
> In the Wildfly integration testsuite,  manual mode section, there are two test cases which are running in a clustered environment when they should not be:
> - RemoteOutboundConnectionReconnectTestCase
> - EJBClientReconnectionTestCase
> These two cases test outbound connections from one server A to another server B, and connection from a client to a server A when the server is stopped and started. There is no clustering functionality being tested.
> Two problems with this situation:
> - exceptions are generated in the logs which result from the fact that the test cases are not being run in the correct environment
> - the fact that the environment is incorrectly configured may also be preventing real bugs from otherwise being detected



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-473) Get rid of external .index
	files
In-Reply-To: <JIRA.12487057.1363099573000@Atlassian.JIRA>
References: <JIRA.12487057.1363099573000@Atlassian.JIRA>
	<JIRA.12487057.1363099573000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487057.1363099573000.90539.1512581049671@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-473:
----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Get rid of external .index files
> --------------------------------
>
>                 Key: WFLY-473
>                 URL: https://issues.jboss.org/browse/WFLY-473
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: David Lloyd
>             Fix For: 10.0.0.Final
>
>
> The external {{*.index}} files have become a problem for distribution.  In 8 we should switch to using internal {{META-INF/PATHS.LIST}} files.  These files should be embedded during build.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2554) Start using wildcards for
	exclusions
In-Reply-To: <JIRA.12525962.1385160746000@Atlassian.JIRA>
References: <JIRA.12525962.1385160746000@Atlassian.JIRA>
	<JIRA.12525962.1385160746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525962.1385160746000.90546.1512581049809@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2554:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Start using wildcards for exclusions
> ------------------------------------
>
>                 Key: WFLY-2554
>                 URL: https://issues.jboss.org/browse/WFLY-2554
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Build System
>            Reporter: David Lloyd
>            Assignee: Paul Gier
>            Priority: Minor
>             Fix For: 10.0.0.Final
>
>
> Maven 3 supports using * for group ID and artifact ID in exclusions.  We should use them throughout the root pom.xml.
> In current Maven versions there's an annoying warning printed, but it can be ignored (the warning is a bug).  See http://jira.codehaus.org/browse/MNG-3832 for discussion and info (the bug says "fix version 3.2" but that's just the version in which the warning was fixed, not the actual feature).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4858) Add tests for permission
 assignment checking when security manager is enabled
In-Reply-To: <JIRA.12576863.1435826209000@Atlassian.JIRA>
References: <JIRA.12576863.1435826209000@Atlassian.JIRA>
	<JIRA.12576863.1435826209000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576863.1435826209000.90550.1512581049886@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4858:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Add tests for permission assignment checking when security manager is enabled
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-4858
>                 URL: https://issues.jboss.org/browse/WFLY-4858
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>             Fix For: 10.0.0.Final
>
>
> Extend test coverage for security manager permissions assignment (in {{permissions.xml}}) and their overrides (in {{jboss-permissions.xml}}).
> Add also tests which check permissions overrides in ear modules (subdeployments).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4894) ORB error message seen on
 shutdown time to time - "IOP01210228: (BAD_OPERATION) This ORB instance has
 been destroyed, so no operations can be performed on it"
In-Reply-To: <JIRA.12577553.1436447152000@Atlassian.JIRA>
References: <JIRA.12577553.1436447152000@Atlassian.JIRA>
	<JIRA.12577553.1436447152000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577553.1436447152000.90556.1512581050023@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4894:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> ORB error message seen on shutdown time to time - "IOP01210228: (BAD_OPERATION) This ORB instance has been destroyed, so no operations can be performed on it"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4894
>                 URL: https://issues.jboss.org/browse/WFLY-4894
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>             Fix For: 10.0.0.Final
>
>
> As jira WFLY-4548 describes there could be seen IIOP errors during server shutdown. As issue was fixed it seemed that the trouble went away. Unfortunatelly in some more testing I'm hitting the exception once again when running crash server tests with transactions under jts.
> {code}
> WARNING [javax.enterprise.resource.corba._INITIALIZING_.rpc.presentation] (Thread-87) "IOP01210228: (BAD_OPERATION) This ORB instance has been destroyed, so no operations can be performed on it": org.omg.CORBA.BAD_     OPERATION:   vmcid: SUN  minor code: 228  completed: No
>  at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbDestroyed(ORBUtilSystemException.java:586)
>  at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbDestroyed(ORBUtilSystemException.java:608)
>  at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
>  at com.sun.corba.se.impl.orb.ORBImpl.isDuringDispatch(ORBImpl.java:1340)
>  at com.sun.corba.se.impl.oa.poa.POAImpl.destroy(POAImpl.java:959)
>  at com.arjuna.orbportability.internal.orbspecific.oa.implementations.POABase.destroyRootPOA(POABase.java:68)
>  at com.arjuna.orbportability.oa.core.OA.destroyRootPOA(OA.java:97)
>  at com.arjuna.orbportability.RootOA.destroy(RootOA.java:91)
>  at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.ORBRunner.run(ORBRunner.java:59)
> {code}
> The scenario is something:
>  - starting server under profile standalone-full.xml with in-vm ActiveMQ messaging
>  - setting server via CLI
>  - setting transaction running under JTS
>  - deploy application containing MDB reading message from ActiveMQ
>  - crash server
>  - start again and doing recovery
>  - stop server (now the exception is shown)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:24:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:24:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5436) Lack of
 EmbeddedCacheManager.undefineConfiguration(String) can cause
 memory/classloader leaks
In-Reply-To: <JIRA.12586755.1443642832000@Atlassian.JIRA>
References: <JIRA.12586755.1443642832000@Atlassian.JIRA>
	<JIRA.12586755.1443642832000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586755.1443642832000.90562.1512581050142@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5436:
-----------------------------
    Fix Version/s: 10.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Lack of EmbeddedCacheManager.undefineConfiguration(String) can cause memory/classloader leaks
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5436
>                 URL: https://issues.jboss.org/browse/WFLY-5436
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.Final
>
>
> EmbeddedCacheManager has defineConfiguration(...) methods for defining a new cache configuration, but has no equivalent "undefine" method.  Consequently, once defined, a cache manager will retains a reference to the cache configuration object for the lifetime of the cache manager.  While this is normally not a big deal, the configuration objects generated by WildFly contain references to the classloaders of foreign modules.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5249) wildfly-hibernate3 quickstart
 fails to validate in eclipse
In-Reply-To: <JIRA.12583388.1441093591000@Atlassian.JIRA>
References: <JIRA.12583388.1441093591000@Atlassian.JIRA>
	<JIRA.12583388.1441093591000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583388.1441093591000.88381.1512577267795@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5249.
----------------------------


> wildfly-hibernate3 quickstart fails to validate in eclipse
> ----------------------------------------------------------
>
>                 Key: WFLY-5249
>                 URL: https://issues.jboss.org/browse/WFLY-5249
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Rob Stryker
>            Assignee: Jason Greene
>             Fix For: 10.0.0.CR1
>
>
> wildfly-hibernate3 quickstart has xml file with following content:
> {code}
> <persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
>    version="2.0">
> {code}
> This fails because it is importing the persistence_2_1.xsd file, but is setting version=2.0.   It must set version=2.1



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4579) BeanManager method getBeans()
 is not available during application initialization
In-Reply-To: <JIRA.12570570.1430727017000@Atlassian.JIRA>
References: <JIRA.12570570.1430727017000@Atlassian.JIRA>
	<JIRA.12570570.1430727017000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570570.1430727017000.88385.1512577268205@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4579.
----------------------------


> BeanManager method getBeans() is not available during application initialization
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-4579
>                 URL: https://issues.jboss.org/browse/WFLY-4579
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final
>         Environment: Windows 7
>            Reporter: Thomas Meyer
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> Deployment of an EAR fails because of this exception:
> 09:34:30,854 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment Project-ejb.jar
> 09:34:30,862 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named ModelContext in deployment unit subdeployment "Project-ejb.jar" of deployment "Project-ear-0.1.0-SNAPSHOT.ear" are as follows:
>         java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/ModelContext!simulator.ModelContext
>         java:app/Project-ejb/ModelContext!simulator.ModelContext
>         java:module/ModelContext!simulator.ModelContext
>         java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/ModelContext
>         java:app/Project-ejb/ModelContext
>         java:module/ModelContext
> 09:34:30,863 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named AccountsBean in deployment unit subdeployment "Project-ejb.jar" of deployment "Project-ear-0.1.0-SNAPSHOT.ear" are as follows:
>         java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/AccountsBean!simulator.AccountsBean
>         java:app/Project-ejb/AccountsBean!simulator.AccountsBean
>         java:module/AccountsBean!simulator.AccountsBean
>         java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/AccountsBean
>         java:app/Project-ejb/AccountsBean
>         java:module/AccountsBean
> 09:34:30,864 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named ContactsBean in deployment unit subdeployment "Project-ejb.jar" of deployment "Project-ear-0.1.0-SNAPSHOT.ear" are as follows:
>         java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/ContactsBean!simulator.ContactsBean
>         java:app/Project-ejb/ContactsBean!simulator.ContactsBean
>         java:module/ContactsBean!simulator.ContactsBean
>         java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/ContactsBean
>         java:app/Project-ejb/ContactsBean
>         java:module/ContactsBean
> 09:34:30,892 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment Project-webapp.war
> 09:34:30,954 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: Project-ear-0.1.0-SNAPSHOT.ear
> 09:34:31,016 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900: 2.2.6 (Final)
> 09:34:31,169 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016008: Starting weld service for deployment Project-ear-0.1.0-SNAPSHOT.ear
> 09:34:32,203 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Mojarra 2.2.8-jbossorg-1 20140822-1131 f?r Kontext '/v1' wird initialisiert.
> 09:34:33,738 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Critical error during deployment: : org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
>         at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerState(BeanManagerProxy.java:246) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
>         at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerState(BeanManagerProxy.java:251) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
>         at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:100) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
>         at com.sun.faces.application.JavaFlowLoaderHelper.loadFlows(JavaFlowLoaderHelper.java:66) [jsf-impl-2.2.8-jbossorg-1.jar:]
>         at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.processEvent(ApplicationAssociate.java:298) [jsf-impl-2.2.8-jbossorg-1.jar:]
>         at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
>         at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2190) [jsf-impl-2.2.8-jbossorg-1.jar:]
>         at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.8-jbossorg-1.jar:]
>         at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:296) [jsf-impl-2.2.8-jbossorg-1.jar:]
>         at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.2.0.Final.jar:8.2.0.Final]
>         at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:692) [jsf-impl-2.2.8-jbossorg-1.jar:]
>         at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:260) [jsf-impl-2.2.8-jbossorg-1.jar:]
>         at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:193) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>         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) [rt.jar:1.8.0_31]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
> 09:34:33,938 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./v1: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./v1: Failed to start service
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
>         at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:222)
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
>         at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>         ... 3 more
> Caused by: java.lang.RuntimeException: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
>         at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:280)
>         at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
>         at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:193)
>         ... 7 more
> Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
>         at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerState(BeanManagerProxy.java:246)
>         at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerState(BeanManagerProxy.java:251)
>         at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:100)
>         at com.sun.faces.application.JavaFlowLoaderHelper.loadFlows(JavaFlowLoaderHelper.java:66)
>         at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.processEvent(ApplicationAssociate.java:298)
>         at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108)
>         at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2190)
>         at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163)
>         at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:296)
>         at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294)
>         at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:692)
>         at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:260)
>         ... 9 more
> 09:34:34,099 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "Project-ear-0.1.0-SNAPSHOT.ear")]) - failure description: {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./v1" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./v1: Failed to start service
>     Caused by: java.lang.RuntimeException: java.lang.RuntimeException: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
>     Caused by: java.lang.RuntimeException: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
>     Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization"}}
> 09:34:34,188 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "Project-ear-0.1.0-SNAPSHOT.ear" (runtime-name : "Project-ear-0.1.0-SNAPSHOT.ear")
> 09:34:34,188 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:
> service jboss.undertow.deployment.default-server.default-host./v1: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./v1: Failed to start service
> The EAR contains:
>  1.) An EJB JAR
>  2.) An WepApp WAR
> The webapp uses JSF and JAX-RS.
> None of our code seesm to be involved.
> The EAR can succesfully deployet on an Weblogic AS.
> When I start the WildFly AS with --debug mode and halt at BeanManagerProxy.getBeans() and directly continue the thread exectuion. the deployment of the EAR file works correctly. Feels like some race condition..
> Any ideas how to fix this?



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 11:21:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4830) Upgrade HAL to 2.8.0
In-Reply-To: <JIRA.12576264.1435233642000@Atlassian.JIRA>
References: <JIRA.12576264.1435233642000@Atlassian.JIRA>
	<JIRA.12576264.1435233642000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576264.1435233642000.88388.1512577268299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4830.
----------------------------


> Upgrade HAL to 2.8.0
> --------------------
>
>                 Key: WFLY-4830
>                 URL: https://issues.jboss.org/browse/WFLY-4830
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 10.0.0.Alpha4
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5107) WFLYCTL0028: Attribute
 'default-stack' in the resource at address '/subsystem=jgroups' is
 deprecated, and may be removed in future version.
In-Reply-To: <JIRA.12581242.1439570487000@Atlassian.JIRA>
References: <JIRA.12581242.1439570487000@Atlassian.JIRA>
	<JIRA.12581242.1439570487000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581242.1439570487000.88392.1512577268966@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5107.
----------------------------


> WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5107
>                 URL: https://issues.jboss.org/browse/WFLY-5107
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Carlton Zachary
>            Assignee: Radoslav Husar
>             Fix For: 10.0.0.Beta2
>
>
> I noticed this message below in the server.log.  Is this message intended or a bug?
> INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 27) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4815)
 AdvancedLdapLoginModuleTestCase fails on RHEL5 and IBM JDK
In-Reply-To: <JIRA.12575835.1434968785000@Atlassian.JIRA>
References: <JIRA.12575835.1434968785000@Atlassian.JIRA>
	<JIRA.12575835.1434968785000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575835.1434968785000.88396.1512577269252@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4815.
----------------------------


>  AdvancedLdapLoginModuleTestCase fails on RHEL5 and IBM JDK
> -----------------------------------------------------------
>
>                 Key: WFLY-4815
>                 URL: https://issues.jboss.org/browse/WFLY-4815
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.0.0.Alpha3
>         Environment: IBM JDK on RHEL 5 (both x86 and x86_64)
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>             Fix For: 10.0.0.Alpha5
>
>
> Upstream of https://bugzilla.redhat.com/show_bug.cgi?id=1206177



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5022) The server requires JASPI
 authentication even if no security-constraint is defined
In-Reply-To: <JIRA.12579586.1438084169000@Atlassian.JIRA>
References: <JIRA.12579586.1438084169000@Atlassian.JIRA>
	<JIRA.12579586.1438084169000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579586.1438084169000.88405.1512577269839@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5022.
----------------------------


> The server requires JASPI authentication even if no security-constraint is defined
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-5022
>                 URL: https://issues.jboss.org/browse/WFLY-5022
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Josef Cacek
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 10.0.0.Beta2
>
>
> If JASPI authentication is configured in security domain, then the server requires authentication even if no security-constraint is defined for web application which uses the security domain.
> With the classic authentication is the behavior correct.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5017) Undertow mod_cluster proxy:
 CLI does not display/control load balancing groups
In-Reply-To: <JIRA.12578633.1437409704000@Atlassian.JIRA>
References: <JIRA.12578633.1437409704000@Atlassian.JIRA>
	<JIRA.12578633.1437409704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578633.1437409704000.88410.1512577270146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-5017.
----------------------------


> Undertow mod_cluster proxy: CLI does not display/control load balancing groups
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-5017
>                 URL: https://issues.jboss.org/browse/WFLY-5017
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Michal Karm Babacek
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 10.0.0.Beta1
>
>
> Thanks to a good foundation established in JBEAP-215, there is an elementary information about registered worker nodes available, e.g.
> {noformat}
> /subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-children-resources(child-type=balancer,recursive=true)
> {
>     "outcome" => "success",
>     "result" => {"mycluster" => {"node" => {
>         "worker-2" => {"context" => {"/clusterbench" => {}}},
>         "worker-1" => {"context" => {"/clusterbench" => {}}}
>     }}}
> }
> {noformat}
> One of the information that is missing is *Load Balancing Group*. This is a {color:red}Blocker{color} issue, because absence of Load Balancing Group display and control capabilities blocks:
> * customer scenarios with rolling upgrades
> * customer scenarios with heterogeneous deployments
> * customer scenarios with clustering migration
> * all test cases linked to Load Balancing Group functionality
> The Load Balancing Group functionality appears to be present, so this issue might be resolved with adding CLI operations.
> {noformat}
> UT005054: MCMP processing, key: JVMRoute, value: worker-2
> UT005054: MCMP processing, key: Domain, value: LB-GROUP-1
> UT005054: MCMP processing, key: Host, value: karm.brq.redhat.com
> UT005054: MCMP processing, key: Maxattempts, value: 1
> UT005054: MCMP processing, key: Port, value: 8029
> UT005054: MCMP processing, key: StickySessionForce, value: No
> UT005054: MCMP processing, key: Type, value: ajp
> UT005054: MCMP processing, key: ping, value: 10
> {noformat}
> Note that the attribute "Domain" actually stands for  "Load Balancing Group" and it is not related to "WildFly Domain".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3739) Change Arquillian containers
 to launch the process using the launcher API in core
In-Reply-To: <JIRA.12549466.1408138654000@Atlassian.JIRA>
References: <JIRA.12549466.1408138654000@Atlassian.JIRA>
	<JIRA.12549466.1408138654000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549466.1408138654000.90189.1512580825898@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3739:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Change Arquillian containers to launch the process using the launcher API in core
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-3739
>                 URL: https://issues.jboss.org/browse/WFLY-3739
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 9.0.0.Final
>
>
> WildFly Core now includes a launcher API to generate the commands and optionally launch a WildFly process. Arquillian should be changed to use this API rather than relying on creating the commands and the process on it's own.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4301) Quickstart ejb-multi-server
	does not work
In-Reply-To: <JIRA.12562117.1422637170000@Atlassian.JIRA>
References: <JIRA.12562117.1422637170000@Atlassian.JIRA>
	<JIRA.12562117.1422637170000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562117.1422637170000.90199.1512580826178@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4301:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Quickstart ejb-multi-server does not work
> -----------------------------------------
>
>                 Key: WFLY-4301
>                 URL: https://issues.jboss.org/browse/WFLY-4301
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>             Fix For: 9.0.0.Final
>
>
> After changing the maven artifactId of the project the created application ear/war files are named different and the deployment script deploy-domain.cli will not work.
> Also the ejb lookup names has change because of this and need to be adapted.
> related commit 10f95488c0a6f765c25d70a7dcbd566e59230fd2



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4119) Support Slow Consumer Policy
In-Reply-To: <JIRA.12558031.1416826299000@Atlassian.JIRA>
References: <JIRA.12558031.1416826299000@Atlassian.JIRA>
	<JIRA.12558031.1416826299000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558031.1416826299000.90204.1512580826281@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4119:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Support Slow Consumer Policy
> ----------------------------
>
>                 Key: WFLY-4119
>                 URL: https://issues.jboss.org/browse/WFLY-4119
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 9.0.0.Final
>
>
> Support HornetQ Slow consumer policy to KILL or NOTIFY if consumers starts to be to slow consuming messages.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1893) Restarting server with a
 disabled DS enables the DS
In-Reply-To: <JIRA.12498787.1376679198000@Atlassian.JIRA>
References: <JIRA.12498787.1376679198000@Atlassian.JIRA>
	<JIRA.12498787.1376679198000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498787.1376679198000.90196.1512580826079@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1893:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Restarting server with a disabled DS enables the DS
> ---------------------------------------------------
>
>                 Key: WFLY-1893
>                 URL: https://issues.jboss.org/browse/WFLY-1893
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Kabir Khan
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.Final
>
>
> See https://issues.jboss.org/browse/WFLY-1874
> If you add a datasource with 
> subsystem=datasources/data-source=Test:add(jndi-name=java:/Test,jta=false,use-ccm=false,connection-url=url,driver-class=org.h2.Driver,driver-name=h2,user-name=user,password=pass,validate-on-match=false,background-validation=false,share-prepared-statements=false)
> it shows up as not enabled/undefined:
> {code}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource{                                                                                                                                         "outcome" => "success",
>     "result" => {
> ...
>         "enabled" => false,
> {code}
> {code}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource(include-defaults=false)
> {
>     "outcome" => "success",
>     "result" => {
> ...        "enabled" => undefined,
> {code}
> This is persisted as 
> {code}
>                <datasource jta="false" jndi-name="java:/Test" pool-name="Test" enabled="false" use-ccm="false">
>                     <connection-url>url</connection-url>
>                     <driver-class>org.h2.Driver</driver-class>
>                     <driver>h2</driver>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <validate-on-match>false</validate-on-match>
>                         <background-validation>false</background-validation>
>                     </validation>
>                     <statement>
>                         <share-prepared-statements>false</share-prepared-statements>
>                     </statement>
>                 </datasource>
> {code}
> Now if you stop and start the server again you end up with enabled=true.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1703) Bump core console to 2.x
In-Reply-To: <JIRA.12496532.1373970556000@Atlassian.JIRA>
References: <JIRA.12496532.1373970556000@Atlassian.JIRA>
	<JIRA.12496532.1373970556000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496532.1373970556000.90208.1512580826424@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1703:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Bump core console to 2.x
> ------------------------
>
>                 Key: WFLY-1703
>                 URL: https://issues.jboss.org/browse/WFLY-1703
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>             Fix For: 9.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be
 added to elements in Transactions Subsystem
In-Reply-To: <JIRA.12556685.1415177547000@Atlassian.JIRA>
References: <JIRA.12556685.1415177547000@Atlassian.JIRA>
	<JIRA.12556685.1415177547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556685.1415177547000.90214.1512580826583@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4054:
-----------------------------
    Fix Version/s: 9.0.0.Final


> Unexpected attribute can be added to elements in Transactions Subsystem
> -----------------------------------------------------------------------
>
>                 Key: WFLY-4054
>                 URL: https://issues.jboss.org/browse/WFLY-4054
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Amos Feng
>            Assignee: Amos Feng
>             Fix For: 9.0.0.Final
>
>
> If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started.
> When you add a random argument to some of the elements in transactions then no error is thrown.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:20:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:20:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2760) Intermittent failure of
 ExternalContextBindingTestCase
In-Reply-To: <JIRA.12529570.1389865466000@Atlassian.JIRA>
References: <JIRA.12529570.1389865466000@Atlassian.JIRA>
	<JIRA.12529570.1389865466000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529570.1389865466000.90218.1512580826709@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2760:
-----------------------------
    Fix Version/s: 9.0.0.Final


>  Intermittent failure of ExternalContextBindingTestCase
> -------------------------------------------------------
>
>                 Key: WFLY-2760
>                 URL: https://issues.jboss.org/browse/WFLY-2760
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>            Priority: Minor
>             Fix For: 9.0.0.Final
>
>
> The server setup task sometimes fails to start the ApacheDS server instance because for some reason, BouncyCastle security provider doesn't get registered (it is added through a maven dependency rather than added to the JDK). This leads to a "connection refused" error during the test when it is trying to connect to the LDAP instance.
> It worked for us if we just programatically forced registration of the BouncyCastleProvider before the initialization of ApacheDS.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5400) Failover of standalone JMS
 client fails with netty (blocking/non-blocking) connector
In-Reply-To: <JIRA.12585935.1443090138000@Atlassian.JIRA>
References: <JIRA.12585935.1443090138000@Atlassian.JIRA>
	<JIRA.12585935.1443090138000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585935.1443090138000.90604.1512581226790@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5400:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Failover of standalone JMS client fails with netty (blocking/non-blocking) connector
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-5400
>                 URL: https://issues.jboss.org/browse/WFLY-5400
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation, JMS
>    Affects Versions: 10.0.0.CR1
>            Reporter: Miroslav Novak
>            Assignee: ANGELA ROBERTSON
>             Fix For: 11.0.0.Final
>
>         Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml
>
>
> Failover of standalone JMS client fails if netty (blocking/non-blocking) connector is used. There are 2 EAP 7.0.0.DR10 (Artemis 1.1.0) servers configured in dedicated topology with shared store.
> If live server is killed then backup activates but client does not failover to it:
> {code}
> ent message with property count: 110867, messageId:ID:20310150-62a0-11e5-ada8-b3332c72af23
> Sent message with property count: 110868, messageId:ID:20310151-62a0-11e5-ada8-b3332c72af23
> Sep 24, 2015 11:39:27 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:39:40 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:39:55 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:40:10 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> {code}
> Attaching live/backup configuration. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7205) Enhance coverage of
 transaction timeout test cases
In-Reply-To: <JIRA.12651795.1474641700000@Atlassian.JIRA>
References: <JIRA.12651795.1474641700000@Atlassian.JIRA>
	<JIRA.12651795.1474641700000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651795.1474641700000.90611.1512581227078@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7205:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Enhance coverage of transaction timeout test cases
> --------------------------------------------------
>
>                 Key: WFLY-7205
>                 URL: https://issues.jboss.org/browse/WFLY-7205
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 10.1.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> There is not much tests which checks behaviour of CMT/BMT EJBs when transaction timeout occurs.
> There should be more such tests.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4539) logging statement to trace
 remoting heartbeat
In-Reply-To: <JIRA.12568820.1429524342000@Atlassian.JIRA>
References: <JIRA.12568820.1429524342000@Atlassian.JIRA>
	<JIRA.12568820.1429524342000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568820.1429524342000.90617.1512581227413@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4539:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> logging statement to trace remoting heartbeat
> ---------------------------------------------
>
>                 Key: WFLY-4539
>                 URL: https://issues.jboss.org/browse/WFLY-4539
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EJB
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Carsten Lichy-Bittendorf
>            Assignee: Peter Palaga
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> you can set the heartbeat on a remoting connection by setting:
> remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL
> What is missing is the option to log on the client when the heartbeat message is fired.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3316) Multi threaded ejb
 invocations via remote-naming produce EJBCLIENT000025 if the Context is
 closed
In-Reply-To: <JIRA.12539854.1399300690000@Atlassian.JIRA>
References: <JIRA.12539854.1399300690000@Atlassian.JIRA>
	<JIRA.12539854.1399300690000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539854.1399300690000.90596.1512581226310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3316:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3316
>                 URL: https://issues.jboss.org/browse/WFLY-3316
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Wolf-Dieter Fink
>            Assignee: Enrique Gonz?lez Mart?nez
>              Labels: ejb, naming, remote-clients, remote-ejb-connection
>             Fix For: 11.0.0.Final
>
>         Attachments: reproducer.zip
>
>
> If a client run multi threads and each Thread use it's own InitialContext the behaviour is unexpected.
> The behaviour is as followed:
> if each invocation create it's own IC and lookup the EJB there is sometimes a EJBCLIENT000025 because one of the one thread has closed the IC until another thread try to invoke an EJB.
> If the IC is reused the failure might happen only if the first Thread has finished the invocations and close the IC during other Threads are still running.
> It looks that the underlying remote connection will be closed if the first IC is closed without respect that there are different IC's created and still in use.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:27:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6321) Create tool to monitor
 clustering thread pool usage
In-Reply-To: <JIRA.12609106.1457115867000@Atlassian.JIRA>
References: <JIRA.12609106.1457115867000@Atlassian.JIRA>
	<JIRA.12609106.1457115867000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12609106.1457115867000.90623.1512581227542@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6321:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Create tool to monitor clustering thread pool usage
> ---------------------------------------------------
>
>                 Key: WFLY-6321
>                 URL: https://issues.jboss.org/browse/WFLY-6321
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> Scheduled executors and thread pools are used widely in JGroups and Infinispan for asynchronously executing tasks.  When thread pools are not adequately sized to the load they are subjected to, this can lead to performance problems. 
> It would be helpful if we could see thread pool usage as a function of elapse time during performance runs, in order to diagnose potential thread pool issues.
> This task will provide a Byteman-based tool to monitor threadpool usage and allow a report to be attached to SmartFrog test jobs.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6104) Too many invocations to a
 remote EJB from multiple threads cause infinite wait
In-Reply-To: <JIRA.12601999.1454326783000@Atlassian.JIRA>
References: <JIRA.12601999.1454326783000@Atlassian.JIRA>
	<JIRA.12601999.1454326783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12601999.1454326783000.90629.1512581227852@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6104:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Too many invocations to a remote EJB from multiple threads cause infinite wait
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-6104
>                 URL: https://issues.jboss.org/browse/WFLY-6104
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting
>    Affects Versions: 10.0.0.Final
>            Reporter: Tomas Hofman
>            Assignee: Tomas Hofman
>             Fix For: 11.0.0.Final
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1302181
>   While a thread (1) of EJB client invokes a remote EJB which needs long
>   processing time and wait for the response, if the other threads complete
>   more than 65536 invocations to the remote EJB, EJBCLIENT000011 message like
>   below occurs in EJB client side and the waiting thread (1) falls into
>   infinite wait for the response.
>     INFO: EJBCLIENT000011: Discarding result for invocation id 0 since no
>     waiting context found
>   All invocations should successfully complete regardless of the number of
>   invocations.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8348) Testsuite TxUtil class
 contain superfluous method enlistTestXAResource
In-Reply-To: <JIRA.12681465.1489400371000@Atlassian.JIRA>
References: <JIRA.12681465.1489400371000@Atlassian.JIRA>
	<JIRA.12681465.1489400371000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12681465.1489400371000.90633.1512581227936@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8348:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Testsuite TxUtil class contain superfluous method enlistTestXAResource
> ----------------------------------------------------------------------
>
>                 Key: WFLY-8348
>                 URL: https://issues.jboss.org/browse/WFLY-8348
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.1.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> With fix for WFLY-7205
> there was introduced ambiguousness on method {{enlistTestXAResource}} in
> https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/transactions/TxTestUtil.java
> This needs to be eliminated and only one such method should exist.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7716) Add tests for XA DataSource
	statistics
In-Reply-To: <JIRA.12664751.1480593012000@Atlassian.JIRA>
References: <JIRA.12664751.1480593012000@Atlassian.JIRA>
	<JIRA.12664751.1480593012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664751.1480593012000.90637.1512581228032@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7716:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Add tests for XA DataSource statistics
> --------------------------------------
>
>                 Key: WFLY-7716
>                 URL: https://issues.jboss.org/browse/WFLY-7716
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Daniel Simko
>            Assignee: Daniel Simko
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> Add new testcase for testing xa-data-source's pool statistics (XACommitCount, XARollbackCount, XAStartCount).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6154) [Migration][WebToUndertow]
 RemoteAddrValve and RemoteHostValve are incorrectly migrated
In-Reply-To: <JIRA.12603221.1455045182000@Atlassian.JIRA>
References: <JIRA.12603221.1455045182000@Atlassian.JIRA>
	<JIRA.12603221.1455045182000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603221.1455045182000.90643.1512581228163@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6154:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> [Migration][WebToUndertow] RemoteAddrValve and RemoteHostValve are incorrectly migrated
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-6154
>                 URL: https://issues.jboss.org/browse/WFLY-6154
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>            Priority: Blocker
>             Fix For: 11.0.0.Final
>
>
> When migrating {{RemoteHostValve}} or {{RemoteAddrValve}} which contains multiple allows or denies or contains both as in \[1\], it is migrated incorrectly. In the resulting expression the acl attribute should be in format {{acl=\{'xxx allow', 'yyy deny'\}}}, but instead it results in {{acl='xxx allow, yyy deny'}} which is incorrect and results in exception when doing any request to the server. 
> Marking as critical as that it was migrated incorrectly the customer will not find out during migration but when actually doing request to the server.
> Might be interesting to [~ehugonnet]
> [1]
> {code:xml}
>  <valve name="request-filter" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve">
>         <param param-name="deny" param-value="10.0.0.1"/>
>         <param param-name="allow" param-value="127.*"/>
>     </valve>
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6707) WildFly Test Suite:
 Integration - XTS is a little bit confusing and needs small cleanup
In-Reply-To: <JIRA.12631227.1465911752000@Atlassian.JIRA>
References: <JIRA.12631227.1465911752000@Atlassian.JIRA>
	<JIRA.12631227.1465911752000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12631227.1465911752000.90649.1512581228405@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6707:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> WildFly Test Suite: Integration - XTS is a little bit confusing and needs small cleanup
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-6707
>                 URL: https://issues.jboss.org/browse/WFLY-6707
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite, XTS
>    Affects Versions: 10.0.0.Final
>            Reporter: Daniel Simko
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> The line https://github.com/wildfly/wildfly/blob/master/testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/wsba/coordinatorcompletion/client/BACoordinatorCompletionTestCase.java#L124 is never reached because exception is thrown from the line before.
> The Javadoc https://github.com/wildfly/wildfly/blob/master/testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/wsba/coordinatorcompletion/service/BACoordinationCompletionParticipant.java is copied from https://github.com/wildfly/quickstart/blob/10.x/wsba-coordinator-completion-simple/src/main/java/org/jboss/as/quickstarts/wsba/coordinatorcompletion/simple/SetParticipantBA.java and doesn't make sense here.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1589) requiredSecret attribute on
 the AJP connector
In-Reply-To: <JIRA.12495134.1372241506000@Atlassian.JIRA>
References: <JIRA.12495134.1372241506000@Atlassian.JIRA>
	<JIRA.12495134.1372241506000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495134.1372241506000.90657.1512581228656@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1589:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> requiredSecret attribute on the AJP connector
> ---------------------------------------------
>
>                 Key: WFLY-1589
>                 URL: https://issues.jboss.org/browse/WFLY-1589
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>         Attachments: requiredsecret.diff, requiredsecret.diff
>
>
> In JBoss 5 I could set the requiredSecret attribute of the AJP connector. This is no longer possible in JBoss AS 7 and WildFly
> This request is to get it implemented similarly to WFLY-254 for tomcatAuthentication



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5232) Naming store is null before
 CDI lifecycle BeforeShutdown event fires
In-Reply-To: <JIRA.12583155.1440773094000@Atlassian.JIRA>
References: <JIRA.12583155.1440773094000@Atlassian.JIRA>
	<JIRA.12583155.1440773094000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583155.1440773094000.90662.1512581228910@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5232:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Naming store is null before CDI lifecycle BeforeShutdown event fires
> --------------------------------------------------------------------
>
>                 Key: WFLY-5232
>                 URL: https://issues.jboss.org/browse/WFLY-5232
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>             Fix For: 11.0.0.Final
>
>         Attachments: reproducer.tar.gz
>
>
> A CDI extension has a BeforeShutdown event handler that looks up the UserTransaction and performs a clean-up operation. If the application is undeployed, all works as expected, but if Wildfly is shut down gracefully the lookup fails.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3904) Unable to enable statistics
 via configuration for resource adapters
In-Reply-To: <JIRA.12553501.1411768981000@Atlassian.JIRA>
References: <JIRA.12553501.1411768981000@Atlassian.JIRA>
	<JIRA.12553501.1411768981000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553501.1411768981000.90669.1512581229307@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3904:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Unable to enable statistics via configuration for resource adapters
> -------------------------------------------------------------------
>
>                 Key: WFLY-3904
>                 URL: https://issues.jboss.org/browse/WFLY-3904
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.1.0.Final
>            Reporter: Daniel Atallah
>            Assignee: Stefano Maestri
>             Fix For: 11.0.0.Final
>
>
> The statistics for  resource adapters are hard-coded to be disabled at startup:
> https://github.com/wildfly/wildfly/blob/47830b44d1bd48c4fcdc2489cecaa3971c45c209/connector/src/main/java/org/jboss/as/connector/deployers/ra/processors/AbstractResourceAdapterDeploymentServiceListener.java#L91
> It's not possible to enable the statistics in a persistent way - it needs to be done each time the servers starts e.g. via jmx.
> Ideally there'd be a "statistics-enabled" attribute on the "<connection-definition>" element in the configuration file in the same way that there is on "<datasource>".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8351) Prepare wildfly for multiply
 dynamic capability parts in core
In-Reply-To: <JIRA.12681493.1489405824000@Atlassian.JIRA>
References: <JIRA.12681493.1489405824000@Atlassian.JIRA>
	<JIRA.12681493.1489405824000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12681493.1489405824000.90675.1512581229934@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8351:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Prepare wildfly for multiply dynamic capability parts in core
> -------------------------------------------------------------
>
>                 Key: WFLY-8351
>                 URL: https://issues.jboss.org/browse/WFLY-8351
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 11.0.0.Final
>
>
> Due to some API changes coming with WFCORE-2202we need to modify code a bit in full before we can merge core PR



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2129) @WebContext on EJB,
 results in Web Service endpoints that doesn't honor neither
 method-level authorization nor general authorization configuration
In-Reply-To: <JIRA.12501191.1379934448000@Atlassian.JIRA>
References: <JIRA.12501191.1379934448000@Atlassian.JIRA>
	<JIRA.12501191.1379934448000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501191.1379934448000.90684.1512581230328@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2129:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2129
>                 URL: https://issues.jboss.org/browse/WFLY-2129
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Web Services
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Mac OS X
>            Reporter: Nicky M?lholm
>            Assignee: Jim Ma
>             Fix For: 11.0.0.Final
>
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc) 
> A simple EJB with a Web service view can illustrate the first problem: 
> {code:java}
> @Stateless 
> @WebService 
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> 	@PermitAll // <-- This doesn't work
> 	//@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> 	// <--- unless you put them on class level 
>     public String sayHello(String name) {
>         System.out.println("******** Greeter.sayHello(" + name + ")");
>         return "Hello " + name;
>     }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>  
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll, at DenyAll, at RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>  
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:27:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8577) Additional privileged blocks
 for JAXWS client running with Security Manager enabled
In-Reply-To: <JIRA.12687616.1492084921000@Atlassian.JIRA>
References: <JIRA.12687616.1492084921000@Atlassian.JIRA>
	<JIRA.12687616.1492084921000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12687616.1492084921000.90689.1512581230431@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8577:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Additional privileged blocks for JAXWS client running with Security Manager enabled
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-8577
>                 URL: https://issues.jboss.org/browse/WFLY-8577
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 11.0.0.Final
>
>
> This is a follow up of CXF-5142 which should enable the JAXWS client to run with Security Manager enabled.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1526) AS7 JConsole scripts ignore
	arguments
In-Reply-To: <JIRA.12494275.1371192583000@Atlassian.JIRA>
References: <JIRA.12494275.1371192583000@Atlassian.JIRA>
	<JIRA.12494275.1371192583000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494275.1371192583000.90694.1512581230564@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-1526:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> AS7 JConsole scripts ignore arguments 
> --------------------------------------
>
>                 Key: WFLY-1526
>                 URL: https://issues.jboss.org/browse/WFLY-1526
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> JConsole scripts ignore arguments, for instance, sh script:
> jconsole -J-Djava.class.path="$CLASSPATH"
> instead of
> jconsole -J-Djava.class.path="$CLASSPATH" "$@"



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6551) Incorrect log message in
 class ClientSessionFactoryImpl
In-Reply-To: <JIRA.12616594.1461548387000@Atlassian.JIRA>
References: <JIRA.12616594.1461548387000@Atlassian.JIRA>
	<JIRA.12616594.1461548387000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616594.1461548387000.90701.1512581230806@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6551:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Incorrect log message in class ClientSessionFactoryImpl
> -------------------------------------------------------
>
>                 Key: WFLY-6551
>                 URL: https://issues.jboss.org/browse/WFLY-6551
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Final
>            Reporter: Chen Maoqian
>            Assignee: Chen Maoqian
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> There is incorrect logging message present in method {{establishNewConnection()}} in class {{org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl}} .
>  
> {noformat}
>    protected RemotingConnection establishNewConnection() {
>      ....
>       RemotingConnection newConnection = clientProtocolManager.connect(...);
>       newConnection.addFailureListener(new DelegatingFailureListener(newConnection.getID()));
>       schedulePing();
>       if (ActiveMQClientLogger.LOGGER.isTraceEnabled()) {
>          ActiveMQClientLogger.LOGGER.trace("returning " + connection);
>       }
>       return newConnection;
>    }
> {noformat}
> Log message says, that it is returning connection (old one, present as an attribute of class),  but connection stored in {{newConnection}} variable is returned (and then it is set as this.connection).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4876) Upgrade AESH from 0.33.15 to
	0.33.16
In-Reply-To: <JIRA.12577178.1436257651000@Atlassian.JIRA>
References: <JIRA.12577178.1436257651000@Atlassian.JIRA>
	<JIRA.12577178.1436257651000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577178.1436257651000.90707.1512581230976@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4876:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Upgrade AESH from 0.33.15 to 0.33.16
> ------------------------------------
>
>                 Key: WFLY-4876
>                 URL: https://issues.jboss.org/browse/WFLY-4876
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Ryan Emerson
>            Assignee: Jason Greene
>             Fix For: 11.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4805) Distributable app causes
 TransferQueueBundler Invalid argument and Topology errors
In-Reply-To: <JIRA.12575550.1434641327000@Atlassian.JIRA>
References: <JIRA.12575550.1434641327000@Atlassian.JIRA>
	<JIRA.12575550.1434641327000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575550.1434641327000.90715.1512581231148@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4805:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Distributable app causes TransferQueueBundler Invalid argument and Topology errors
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-4805
>                 URL: https://issues.jboss.org/browse/WFLY-4805
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Alpha4
>         Environment: Oracle JDK 1.8, Open JDK 1.8, RHEL 7
>            Reporter: Michal Karm Babacek
>            Assignee: Romain Pelisse
>              Labels: rpelisse_wip
>             Fix For: 11.0.0.Final
>
>         Attachments: clusterbench.war, configs.zip, logs.zip
>
>
> Simple shutdown failover tests are failing due to apparent error in / misconfiguration of the distributed cache.
> If one follows the aforementioned steps to reproduce, the following symptoms appear:
>  * Variations on {noformat}SEVERE [org.jgroups.protocols.UDP] (TransferQueueBundler,ee,rhel7gax86-64) JGRP000029: rhel7gax86-64: failed sending message to rhel7gax86-64 (59 bytes): java.io.IOException: Invalid argument, headers: UNICAST3: ACK, seqno=9410, ts=217, UDP: [cluster_name=ee]{noformat}
>  * Failures of this kind: {noformat}ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (transport-thread--p2-t12) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 11
>     at org.infinispan.statetransfer.StateTransferLockImpl.waitForTransactionData(StateTransferLockImpl.java:92)
>     at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTransactionData(BaseStateTransferInterceptor.java:96)
>     at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:285)
>     at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:254)
>     at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:130)
>     at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
>     at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
>     at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
>     at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
>     at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
>     at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
>     at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
>     at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
>     at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
>     at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
>     at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
>     at org.wildfly.clustering.server.registry.CacheRegistry.topologyChanged(CacheRegistry.java:152)
>     at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:497)
>     at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
>     at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
>     at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
>     at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1180)
>     at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1139)
>     at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1105)
>     at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyTopologyChanged(CacheNotifierImpl.java:560)
>     at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:201)
>     at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:45)
>     at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:113)
>     at org.infinispan.topology.LocalTopologyManagerImpl.doHandleTopologyUpdate(LocalTopologyManagerImpl.java:285)
>     at org.infinispan.topology.LocalTopologyManagerImpl$1.run(LocalTopologyManagerImpl.java:218)
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>     at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.runInternal(SemaphoreCompletionService.java:166)
>     at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.run(SemaphoreCompletionService.java:144)
>     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){noformat}
>  * Warnings such as: {noformat}WARN  [org.infinispan.transaction.impl.TransactionTable] (TxCleanupService,dist,rhel7gax86-64) ISPN000326: Remote transaction GlobalTransaction:<rhel7gax86-64>:9373:remote timed out. Rolling back after 70810 ms{noformat}
> Logs from one of such play & test scenarios are attached: [^logs.zip], [^configs.zip].
> Any ideas which configuration directive or application setting might be at the bottom of this?
> Needless to say any such test passes without any error with EAP 6.4 and 6.3 both with shutdown and undeploy failover scenarios.
> Thx for comments.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Wrong HTTP error code for
 Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.90725.1512581231541@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7295:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Wrong HTTP error code for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-7295
>                 URL: https://issues.jboss.org/browse/WFLY-7295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Zach Rhoads
>            Priority: Critical
>             Fix For: 11.0.0.Final
>
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	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 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:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	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:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> 	... 45 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	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 com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	... 67 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3690) Not possible to start XTS
 transaction on IPv6 with server bound to ::1
In-Reply-To: <JIRA.12547830.1406708496000@Atlassian.JIRA>
References: <JIRA.12547830.1406708496000@Atlassian.JIRA>
	<JIRA.12547830.1406708496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547830.1406708496000.90733.1512581232101@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3690:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Not possible to start XTS transaction on IPv6 with server bound to ::1
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3690
>                 URL: https://issues.jboss.org/browse/WFLY-3690
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions, XTS
>            Reporter: Stefano Maestri
>            Assignee: Amos Feng
>             Fix For: 11.0.0.Final
>
>
> Currently we have  the following configuration element: <xts-environment url="http://${jboss.bind.address:127.0.0.1}:8080/ws-c11/ActivationService"/>
> If bind address is set to ::1, then xts environment URL becomes http://::1:8080/ws-c11/ActivationService. This is incorrect, because IPv6 address with port number in it suppose to have brackets.
> we could need to split url in 4 different attribute:
> * protocol
> * host
> * port 
> * path
> but there isn't a easy way to do the transformer by adding these new attributes. So it's just another solution to split the url and check the address if startsWith ::1, then it needs to add the brackets and join them again.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4260) Schema validation errors
 against jboss-service_7_0.xsd
In-Reply-To: <JIRA.12561120.1421444178000@Atlassian.JIRA>
References: <JIRA.12561120.1421444178000@Atlassian.JIRA>
	<JIRA.12561120.1421444178000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561120.1421444178000.90739.1512581232530@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4260:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Schema validation errors against jboss-service_7_0.xsd 
> -------------------------------------------------------
>
>                 Key: WFLY-4260
>                 URL: https://issues.jboss.org/browse/WFLY-4260
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Sande Gilda
>            Assignee: Tomas Hofman
>             Fix For: 11.0.0.Final
>
>
> When you import a quickstart containing a jboss-service.xml file, you get the following XML:
> cvc-complex-type.2.3: Element 'attribute' cannot have character [children], because the type's content type is element-only.	
> The quickstart source is located here: 
> https://github.com/jboss-developer/jboss-eap-quickstarts/tree/6.4.x/helloworld-mbean
> I searched the https://github.com/jbossas/jboss-eap/ source code for other jboss-service.xml examples, and found a few with syntax similar to what the quickstarts use:
> * sar/src/test/resources/test/serviceXmlDeployment.jar/META-INF/jboss-service.xml
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/sar/injection/jboss-service.xml
> * testsuite/integration/smoke/src/test/java/org/jboss/as/test/smoke/sar/jboss-service.xml
> * arquillian/container-managed/src/test/resources/sar-example.sar/META-INF/jboss-service.xml
> * arquillian/container-remote/src/test/resources/sar-example.sar/META-INF/jboss-service.xml
> There seems to be an error in the schema:
> http://www.jboss.org/schema/jbossas/jboss-service_7_0.xsd
> The quickstart bug is located here: https://bugzilla.redhat.com/show_bug.cgi?id=1178782



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6155) [Migration][WebToUndertow]
 RemoteIpValve - protocolHeaderHttpsValue and proxiesHeader are neither
 migrated and neither migration warning is shown
In-Reply-To: <JIRA.12603226.1455048207000@Atlassian.JIRA>
References: <JIRA.12603226.1455048207000@Atlassian.JIRA>
	<JIRA.12603226.1455048207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603226.1455048207000.90745.1512581232957@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6155:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> [Migration][WebToUndertow] RemoteIpValve - protocolHeaderHttpsValue and proxiesHeader are neither migrated and neither migration warning is shown
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6155
>                 URL: https://issues.jboss.org/browse/WFLY-6155
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>            Priority: Critical
>             Fix For: 11.0.0.Final
>
>
> When migrating {{RemoteIpValve}} which has defined params {{proxiesHeader}} and {{protocolHeaderHttpsValue}} these params are neither migrated nor migration warning is shown.
> If those params are not migratable, there should be printed at least migration warning for them.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6107) WildFly AccessLog valve
 migration is not taking the condition parameter into account
In-Reply-To: <JIRA.12602090.1454345702000@Atlassian.JIRA>
References: <JIRA.12602090.1454345702000@Atlassian.JIRA>
	<JIRA.12602090.1454345702000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12602090.1454345702000.90750.1512581233542@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6107:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> WildFly AccessLog valve migration is not taking the condition parameter into account
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-6107
>                 URL: https://issues.jboss.org/browse/WFLY-6107
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:13 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7202) generic-jms-ra's
 JmsMCFProperties.getSessionDefaultType returns incorrect value for session
 type
In-Reply-To: <JIRA.12651680.1474619783000@Atlassian.JIRA>
References: <JIRA.12651680.1474619783000@Atlassian.JIRA>
	<JIRA.12651680.1474619783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651680.1474619783000.90758.1512581233908@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7202:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7202
>                 URL: https://issues.jboss.org/browse/WFLY-7202
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Tom Ross
>            Assignee: Tom Ross
>             Fix For: 11.0.0.Final
>
>
> The code snippet shows that the method returns wrong type.
> {noformat}
> public String getSessionDefaultType() {
>         if (type == JmsConnectionFactory.AGNOSTIC)
>             return "agnostic";
>         else if (type == JmsConnectionFactory.QUEUE)
>             return TOPIC_TYPE;
>         else
>             return QUEUE_TYPE;
>     }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:14 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8813) Move javax.json module to
	WildFly Core
In-Reply-To: <JIRA.12693191.1495212348000@Atlassian.JIRA>
References: <JIRA.12693191.1495212348000@Atlassian.JIRA>
	<JIRA.12693191.1495212348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693191.1495212348000.90762.1512581234155@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8813:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Move javax.json module to WildFly Core
> --------------------------------------
>
>                 Key: WFLY-8813
>                 URL: https://issues.jboss.org/browse/WFLY-8813
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>            Priority: Critical
>             Fix For: 11.0.0.Final
>
>
> The Elytron subsystem has been moved to WildFly Core, the Elytron audit logger makes use of  JSON so this module is required (Currently marked as optional).
> Once available the module dependency from the org.wildfly.security.elytron-private module should also not be marked as optional.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:14 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6153) [Migration][WebToUndertow]
 RemoteIpValve is not correctly migrated
In-Reply-To: <JIRA.12603219.1455045054000@Atlassian.JIRA>
References: <JIRA.12603219.1455045054000@Atlassian.JIRA>
	<JIRA.12603219.1455045054000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603219.1455045054000.90775.1512581234819@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6153:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> [Migration][WebToUndertow] RemoteIpValve is not correctly migrated
> ------------------------------------------------------------------
>
>                 Key: WFLY-6153
>                 URL: https://issues.jboss.org/browse/WFLY-6153
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>            Priority: Blocker
>             Fix For: 11.0.0.Final
>
>
> When migrating RemoteIpValve which looks like this 
> {code:xml}
>  <valve name="remote-ip-valve" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteIpValve">
>         <param param-name="httpServerPort" param-value="8080"/>
>         <param param-name="httpsServerPort" param-value="8443"/>
>         <param param-name="internalProxies" param-value="192.*|127.*"/>
>         <param param-name="trustedProxies" param-value="10.*"/>
>         <param param-name="protocolHeaderHttpsValue" param-value="https"/>
>         <param param-name="protocolHeader" param-value="X-Forwarded-Proto"/>
>         <param param-name="remoteIpHeader" param-value="X-Forwarded-For"/>
>         <param param-name="proxiesHeader" param-value="X-Forwarded-By"/>
>     </valve>
> {code}
> it is migrated to expression filter looking like this
> {noformat}
> <expression-filter expression="regexp(pattern=&quot;10.*&quot;, value=%{i, x-forwarded-for}, full-match=true) and regexp(pattern=&quot;192.*|127.*&quot;, value=%{i, x-forwarded-for}, full-match=true) -&gt; { proxy-peer-address(); }" name="remote-ip-valve"/>
> {noformat}
> When doing request to http://127.0.0.1:8080/ it fails with 500 and this exception in log
> {noformat}
> 14:06:53,648 ERROR [io.undertow.request] (default I/O-4) UT005071: Undertow request failed HttpServerExchange{ GET / request {Accept=[*/*], User-Agent=[curl/7.43.0-DEV], Host=[127.0.0.1:8080]} response {}}: java.lang.IllegalArgumentException: UT000045: Error parsing predicated handler string Expecting , or ):
> regexp(pattern="10.*", value=%{i, x-forwarded-for}, full-match=true) and regexp(pattern="192.*|127.*", value=%{i, x-forwarded-for}, full-match=true) -> { proxy-peer-address(); }
>                                                                                                                                                                                  ^
> 	at io.undertow.server.handlers.builder.PredicatedHandlersParser.error(PredicatedHandlersParser.java:727)
> 	at io.undertow.server.handlers.builder.PredicatedHandlersParser.parseExpression(PredicatedHandlersParser.java:506)
> 	at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:381)
> 	at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:322)
> 	at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:85)
> 	at org.wildfly.extension.undertow.filters.ExpressionFilterDefinition.createHttpHandler(ExpressionFilterDefinition.java:88)
> 	at org.wildfly.extension.undertow.filters.FilterService.createHttpHandler(FilterService.java:57)
> 	at org.wildfly.extension.undertow.filters.FilterRef.createHttpHandler(FilterRef.java:69)
> 	at org.wildfly.extension.undertow.LocationService.configureHandlerChain(LocationService.java:96)
> 	at org.wildfly.extension.undertow.Host.configureRootHandler(Host.java:117)
> 	at org.wildfly.extension.undertow.Host.getOrCreateRootHandler(Host.java:171)
> 	at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:285)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:64)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:233)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:131)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:145)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:121)
> 	at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
> {noformat}
> The exception is caused by not having in quotes the '%\{i, x-forwarded-for\}'.
> Also there is no predicate named {{regexp}}, the correct name is {{regex}}.
> As this is hidden to the customer during the migration operation and is not visible before customer sends request to the server marking as blocker.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6122) It is not possible to set
 HTTP/2 options on a connector
In-Reply-To: <JIRA.12602499.1454549996000@Atlassian.JIRA>
References: <JIRA.12602499.1454549996000@Atlassian.JIRA>
	<JIRA.12602499.1454549996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12602499.1454549996000.90780.1512581235249@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6122:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> It is not possible to set HTTP/2 options on a connector
> -------------------------------------------------------
>
>                 Key: WFLY-6122
>                 URL: https://issues.jboss.org/browse/WFLY-6122
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 11.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4763) Include org.jboss.invocation
 in group ids that are synced to Maven central
In-Reply-To: <JIRA.12574359.1433854874000@Atlassian.JIRA>
References: <JIRA.12574359.1433854874000@Atlassian.JIRA>
	<JIRA.12574359.1433854874000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574359.1433854874000.90785.1512581235565@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4763:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Include org.jboss.invocation in group ids that are synced to Maven central
> --------------------------------------------------------------------------
>
>                 Key: WFLY-4763
>                 URL: https://issues.jboss.org/browse/WFLY-4763
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Build System
>            Reporter: jaikiran pai
>            Assignee: Paul Gier
>             Fix For: 11.0.0.Final
>
>
> The jboss-invocation module under the org.jboss.invocation group (https://github.com/jbossas/jboss-invocation/ - project home) isn't available in Maven central unlike most of the other org.jboss projects. 
> jboss-invocation is part of WildFly dependencies. Please include the org.jboss.invocation group id in the groups that are synced to Maven central.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:15 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:15 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8731) Unable to inject EJBs into
	web resources
In-Reply-To: <JIRA.12691144.1494302677000@Atlassian.JIRA>
References: <JIRA.12691144.1494302677000@Atlassian.JIRA>
	<JIRA.12691144.1494302677000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12691144.1494302677000.90791.1512581235793@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8731:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Unable to inject EJBs into web resources
> ----------------------------------------
>
>                 Key: WFLY-8731
>                 URL: https://issues.jboss.org/browse/WFLY-8731
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB, Web (Undertow)
>    Affects Versions: 10.0.0.Final
>         Environment: WildFly 10.0 on Windows 10
>            Reporter: Archimedes Trajano
>            Assignee: Stuart Douglas
>             Fix For: 11.0.0.Final
>
>
> There's an old bug on https://issues.jboss.org/browse/JBAS-8818 that talks about this issue on JBoss, but it still applies on WildFly up until now.
> Their comment was based on just WebListener, but I found it applied to the following as well
> * WebServlet
> * WebService (code first and contract first)
> * JAX-RS paths.
> One other thing to note, converting to @EJB from @Inject created another problem, but I'd rather get @Inject working first.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7103) In elytron security domain
 add operation the realms attribute is not marked as required even though it
 is not nillable and has no default value with no default value
In-Reply-To: <JIRA.12650102.1473845103000@Atlassian.JIRA>
References: <JIRA.12650102.1473845103000@Atlassian.JIRA>
	<JIRA.12650102.1473845103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650102.1473845103000.90801.1512581236124@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7103:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7103
>                 URL: https://issues.jboss.org/browse/WFLY-7103
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Radim Hatlapatka
>            Assignee: Jan Kalina
>             Fix For: 11.0.0.Final
>
>
> When reading description of the {{add}} operation for elytron security domain => {{/subsystem=elytron/security-domain=test-domain:read-operation-description(name=add)}}, the realms attribute has set required to false. Still it needs to be defined as part of {{add}} operation as it is not nillable.
> If it is really mandatory, it should be marked as required.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting
 to topic using http-remoting and JNDI fails when server is behind NAT
 firewall
In-Reply-To: <JIRA.12574744.1434045061000@Atlassian.JIRA>
References: <JIRA.12574744.1434045061000@Atlassian.JIRA>
	<JIRA.12574744.1434045061000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574744.1434045061000.90809.1512581236482@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4769:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall 
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4769
>                 URL: https://issues.jboss.org/browse/WFLY-4769
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
>         Environment: RedHat7
>            Reporter: George Turner
>            Assignee: Jeff Mesnil
>             Fix For: 11.0.0.Final
>
>
> Server is behind NAT firewall.  Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> 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 com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
>   at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
>   at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
>   at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
>   ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>  
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration at 2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
>   name = {java.lang.String at 2198} "http-connector"
>   factoryClassName = {java.lang.String at 2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
>   params = {java.util.HashMap at 2200}  size = 4
>    0 = {java.util.HashMap$Node at 2203} "port" -> "8080"
>    1 = {java.util.HashMap$Node at 2204} "host" -> "10.10.20.77"
>    2 = {java.util.HashMap$Node at 2205} "http-upgrade-enabled" -> "true"
>    3 = {java.util.HashMap$Node at 2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7214) Warning of
 IllegalStateException on test-connection-pool for DataSources added after
 previous failure addition
In-Reply-To: <JIRA.12651865.1474859628000@Atlassian.JIRA>
References: <JIRA.12651865.1474859628000@Atlassian.JIRA>
	<JIRA.12651865.1474859628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651865.1474859628000.90814.1512581236626@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7214:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Warning of IllegalStateException on test-connection-pool for DataSources added after previous failure addition
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7214
>                 URL: https://issues.jboss.org/browse/WFLY-7214
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>             Fix For: 11.0.0.Final
>
>
> When a data-source was failed to be added because of missing connection-properties:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2, connection-url="jdbc:h2:test")
> {code}
> , it can be added by correcting the information, like:
> {code:}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test")
> {"outcome" => "success"}
> {code}
> But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source:
> {code:}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=XXX:test-connection-in-pool()
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid",
>     "rolled-back" => true
> }
> {code}
> {panel:title=NOTE FOR THE VERIFY}
> Changing the Step 1 to: 
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2)
> {code}
> for the verifying, because of with fixing of https://issues.jboss.org/browse/JBJCA-1331 (also fixed in ironjacamar-1.3.5.Final), the original step 1 will not cause problems any more.
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:16 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6369) CXF-6799:
 java.lang.ClassCastException:
 sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl cannot be cast
 to java.lang.reflect.TypeVariable
In-Reply-To: <JIRA.12610404.1458024674000@Atlassian.JIRA>
References: <JIRA.12610404.1458024674000@Atlassian.JIRA>
	<JIRA.12610404.1458024674000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610404.1458024674000.90820.1512581236935@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6369:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> CXF-6799: java.lang.ClassCastException: sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl cannot be cast to java.lang.reflect.TypeVariable
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6369
>                 URL: https://issues.jboss.org/browse/WFLY-6369
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Bartosz Baranowski
>            Assignee: Chao Wang
>             Fix For: 11.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7499) Elytron "expressions-allowed"
 => false attributes
In-Reply-To: <JIRA.12659685.1478505614000@Atlassian.JIRA>
References: <JIRA.12659685.1478505614000@Atlassian.JIRA>
	<JIRA.12659685.1478505614000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659685.1478505614000.90828.1512581237168@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7499:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Elytron "expressions-allowed" => false attributes
> -------------------------------------------------
>
>                 Key: WFLY-7499
>                 URL: https://issues.jboss.org/browse/WFLY-7499
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>              Labels: user_experience
>             Fix For: 11.0.0.Final
>
>
> Please change these attributes to {{"expressions-allowed" => true}} if reasonable
> {code}
> /configurable-sasl-server-factory/protocol
> /configurable-sasl-server-factory/server-name
> /filesystem-realm/levels
> /token-realm/public-key
> /token-realm/principal-claim
> /token-realm/oauth2-introspection/host-name-verification-policy
> /token-realm/oauth2-introspection/introspection-url
> /token-realm/oauth2-introspection/client-secret
> /token-realm/oauth2-introspection/client-id
> /token-realm/oauth2-introspection/public-key
> /token-realm/oauth2-introspection/token-realm
> /jdbc-realm/principal-query/sql
> /jdbc-realm/principal-query/data-source
> /jdbc-realm/clear-password-mapper/password-index
> /jdbc-realm/bcrypt-mapper/password-index
> /jdbc-realm/bcrypt-mapper/salt-index
> /jdbc-realm/bcrypt-mapper/iteration-count-index
> /jdbc-realm/salted-simple-digest-mapper/algorithm
> /jdbc-realm/salted-simple-digest-mapper/password-index
> /jdbc-realm/salted-simple-digest-mapper/salt-index
> /jdbc-realm/simple-digest-mapper/password-index
> /jdbc-realm/scram-mapper/algorithm
> /jdbc-realm/scram-mapper/password-index
> /jdbc-realm/scram-mapper/salt-index
> /jdbc-realm/scram-mapper/iteration-count-index
> /security-domain/default-realm 
> These applies to key-store and key-manager:
> */credential-reference/store
> */credential-reference/alias
> */credential-reference/type
> */credential-reference/clear-text
> {code}
> These are not marked as capability reference. But seems referencing another service, so not sure if it is issue in these cases:
> * /jdbc-realm/principal-query/data-source
> * /security-domain/default-realm 
> * /credential-reference/store
> "Collection of primitives" , e.g. LIST of STRING, OBJECT of STRING :
> {code}
> /configurable-sasl-server-factory/properties
> /custom-role-mapper/configuration
> /mapped-regex-realm-mapper/realm-map
> /x500-attribute-principal-decoder/required-oids
> /custom-permission-mapper/configuration
> /configurable-http-server-mechanism-factory/properties
> /custom-name-rewriter/configuration
> /custom-principal-decoder/configuration
> /custom-realm-mapper/configuration
> /custom-modifiable-realm/configuration
> /custom-credential-security-factory/configuration
> /custom-role-decoder/configuration
> /custom-realm/configuration
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:17 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:17 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7149) Unable to remove elytron
 subsystem with defined properties-realm
In-Reply-To: <JIRA.12650995.1474371851000@Atlassian.JIRA>
References: <JIRA.12650995.1474371851000@Atlassian.JIRA>
	<JIRA.12650995.1474371851000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650995.1474371851000.90837.1512581237661@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7149:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Unable to remove elytron subsystem with defined properties-realm
> ----------------------------------------------------------------
>
>                 Key: WFLY-7149
>                 URL: https://issues.jboss.org/browse/WFLY-7149
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Radim Hatlapatka
>            Assignee: Bartosz Baranowski
>            Priority: Critical
>             Fix For: 11.0.0.Final
>
>
> When having elytron subsystem with only defined property-realm and calling remove on the subsystem, it fails due unsatisfied dependencies \[1\]. The subsystem is created from scratch with no dependencies outside of the subsystem => it shouldn't fail to remove.
> \[1\]
> {noformat}
> [standalone at localhost:9990 /] /subsystem=elytron:remove
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service elytron.security-properties was depended upon by service org.wildfly.security.security-realm.elytron-security
> Service elytron.core-service was depended upon by service org.wildfly.security.security-realm.elytron-security",
>     "rolled-back" => true
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8843) Calling an EJB hangs at
	getPeerIdentity
In-Reply-To: <JIRA.12694289.1495717330000@Atlassian.JIRA>
References: <JIRA.12694289.1495717330000@Atlassian.JIRA>
	<JIRA.12694289.1495717330000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12694289.1495717330000.90850.1512581238298@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8843:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Calling an EJB hangs at getPeerIdentity
> ---------------------------------------
>
>                 Key: WFLY-8843
>                 URL: https://issues.jboss.org/browse/WFLY-8843
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Richard Jan?k
>            Assignee: David Lloyd
>             Fix For: 11.0.0.Final
>
>         Attachments: server-dump-1.txt, server-dump-2.txt, surefire-booter-dump-1.txt
>
>
> I'm looking up a stateless EJB and the call hangs indefinitely with current wildfly master. I'm doing the following:
> {code:java}
>     @Before
>     public void setUpAdminObjects() throws NamingException {
>         server1Proxy = lookupAdminObject(TestSuiteEnvironment.getServerAddress(), "8080");
>         server2Proxy = lookupAdminObject(TestSuiteEnvironment.getServerAddress(), "8180");
>         Assert.assertNotNull(server1Proxy);
>         Assert.assertNotNull(server2Proxy);
>     }
>     private DwmAdminObjectEjb lookupAdminObject(String address, String port) throws NamingException {
>         Properties properties = new Properties();
>         properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
>         properties.put(Context.PROVIDER_URL, String.format("%s%s:%s", "http-remoting://", address, port));
>         Context context = new InitialContext(properties);
>         String ejbExportedName = String.format("%s/%s/%s!%s", "dwm-ejb-application", "dwm-ejb-module",
>                 DwmAdminObjectEjbImpl.class.getSimpleName(), DwmAdminObjectEjb.class.getCanonicalName());
>         return (DwmAdminObjectEjb) context.lookup(ejbExportedName);
>     }
> {code}
> That hangs at {{context.lookup()}}. Note that I am aware that the old {{InitialContextFactory}} is deprecated, but the new one doesn't make any difference. I'll eventually replace it anyway.
> You can reproduce it with something like:
> {noformat}
> git remote add rjanik git at github.com:LittleJohnII/wildfly.git
> git fetch rjanik ; git checkout rjanik/eap7-495
> mvn clean install -DskipTests ; cd testsuite/integration/manualmode
> mvn clean test -Dtest=Dwm*TestCase -Djboss.server.config.file.name=standalone-ha.xml -DtrimStackTrace=false
> {noformat}
> Warning: the issue looks somewhat random - I reproduce it on every test run, but sometimes one or two testcases pass before it hangs.
> I also took a thread dump of the two servers and the client that is started by the test. The server thread dumps contain nothing interesting to me, but the client dump shows that it is waiting to get the {{ConnectionPeerIdentity}}.
> {noformat}
> "main" #1 prio=5 os_prio=0 tid=0x00007fa824009000 nid=0x4ad8 waiting on condition [0x00007fa82a6f3000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f7a68820> (a org.xnio.FutureResult$1)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at org.xnio.AbstractIoFuture.await(AbstractIoFuture.java:419)
> 	at org.xnio.AbstractIoFuture.get(AbstractIoFuture.java:535)
> 	at org.wildfly.naming.client.remote.SingleRemoteNamingProvider.getPeerIdentity(SingleRemoteNamingProvider.java:110)
> 	at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:69)
> 	at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:109)
> 	at org.wildfly.naming.client.remote.RemoteContext$$Lambda$122/532677950.apply(Unknown Source)
> 	at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:115)
> 	at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:108)
> 	at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:78)
> 	at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:64)
> 	at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:153)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.manualmode.jca.workmanager.distributed.AbstractDwmTestCase.lookupAdminObject(AbstractDwmTestCase.java:342)
> 	at org.jboss.as.test.manualmode.jca.workmanager.distributed.AbstractDwmTestCase.setUpAdminObjects(AbstractDwmTestCase.java:326)
> 	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.RunBefores.evaluate(RunBefores.java:24)
> 	at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:463)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:108)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:241)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312)
> 	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.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	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.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> I'll attach all the thread dumps too.
> Bisecting the commits in WFLY identified this commit as the culprit:
>   {{deebbdf}} Upgrade WildFly Core to 3.0.0.Beta22.
> Notable upgrade in 3.0.0.Beta22 was Elytron. Because of that and because the client hangs at {{getPeerIdentity()}}, I added the security component.
> The same scenario works without issues prior to this commit, so I assume I'm not just doing things wrong. Even if I'm doing something wrong, which is possible, I believe the client shouldn't just hang, but should instead fire an exception. If you see any issues with my code I'll gladly fix them too.
> Not yet found in JBEAP, current version DR18 has wildfly-core Beta21, this will be present in DR19. The current master is 4a705cf89c90b5893b777fb0aa8188a01942a019.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:27:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5742) Fix test coverage for @RunAs
	in servlets
In-Reply-To: <JIRA.12594370.1448621939000@Atlassian.JIRA>
References: <JIRA.12594370.1448621939000@Atlassian.JIRA>
	<JIRA.12594370.1448621939000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594370.1448621939000.90857.1512581238612@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5742:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Fix test coverage for @RunAs in servlets
> ----------------------------------------
>
>                 Key: WFLY-5742
>                 URL: https://issues.jboss.org/browse/WFLY-5742
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Test Suite
>    Affects Versions: 10.0.0.CR4
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Lukas
>             Fix For: 11.0.0.Final
>
>
> Test coverage for {{@RunAs}} annotated servlets testing is not sufficient in the server.
> The {{WebSecurityRunAsTestCase}} in {{testsuite/integration/basic}} doesn't test the behavior correctly as mentioned in [this comment|https://issues.jboss.org/browse/WFLY-5015?focusedCommentId=13100897&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13100897] of WFLY-5015.
> I suggest to move the coverage to manualmode to be able to test also the behavior of {{@RunAs}} annotated {{HttpServlet.destroy()}} method during AS server shutdown.
> Possible "sun-shine" test scenario:
> * prepare deployment 
> ** use init parameter to configure path to a file which will serve as exceptions-counter for the application
> ** add EJB annotated with {{@RolesAllowed("Admin")}}
> ** add {{@RunAs("Admin")}} annotated servlet which calls the EJB in {{init()}}, {{doGet()}} and {{destroy()}} methods - if exception is thrown it increases the counter in the file (init param)
> * start server
> * deploy the test deployment
> * make call to the servlet
> * stop the server
> * start the server again
> * make call to the servlet
> * undeploy test deployment
> * check the counter (in file) if the exceptions count is 0
> Create "cloudy" scenarios based on modifications of the "sun-shine" one. (E.g. alter the run-as role name used in servlet and check the EJB call falls in all cases)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:18 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:18 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9066) URLBindingTestCase fails with
 security manager
In-Reply-To: <JIRA.12701132.1499692489000@Atlassian.JIRA>
References: <JIRA.12701132.1499692489000@Atlassian.JIRA>
	<JIRA.12701132.1499692489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12701132.1499692489000.90863.1512581238870@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-9066:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> URLBindingTestCase fails with security manager
> ----------------------------------------------
>
>                 Key: WFLY-9066
>                 URL: https://issues.jboss.org/browse/WFLY-9066
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 11.0.0.Beta1
>            Reporter: Ondrej Kotek
>            Assignee: Yeray Borges
>              Labels: security-manager
>             Fix For: 11.0.0.Final
>
>
> {{URLBindingTestCase}} fails with security manager because of missing permissions ({{RemotingPermission("createEndpoint")}} and {{RemotingPermission("connect")}}) and dependency {{org.jboss.remoting}}. After adding the permissions and dependency, there is another missing permission:
> {noformat}
> ERROR [org.xnio.listener] (XNIO-1 I/O-1) XNIO001007: A channel event listener threw an exception: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/okotek/git/wildfly/dist/target/wildfly-11.0.0.Beta1-SNAPSHOT/modules/system/layers/base/org/wildfly/security/elytron-private/main/wildfly-elytron-1.1.0.CR2.jar" "read")" in code source "(vfs:/content/URLBindingTestCaseBean.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.URLBindingTestCaseBean.jar" from Service Module Loader")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350)
> 	at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137)
> 	at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81)
> 	at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> 	at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> 	at java.net.URL.openStream(URL.java:1045)
> 	at java.util.ServiceLoader.parse(ServiceLoader.java:304)
> 	at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
> 	at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
> 	at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
> 	at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
> 	at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
> 	at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> 	at org.wildfly.security.util.ServiceLoaderSupplier.get(ServiceLoaderSupplier.java:55)
> 	at org.wildfly.security.util.ServiceLoaderSupplier.get(ServiceLoaderSupplier.java:35)
> 	at org.wildfly.security.util.ProviderUtil$1.get(ProviderUtil.java:139)
> 	at org.wildfly.security.util.ProviderUtil$1.get(ProviderUtil.java:127)
> 	at org.wildfly.security.sasl.util.SecurityProviderSaslClientFactory.createSaslClient(SecurityProviderSaslClientFactory.java:84)
> 	at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
> 	at org.wildfly.security.sasl.util.ProtocolSaslClientFactory.createSaslClient(ProtocolSaslClientFactory.java:50)
> 	at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
> 	at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
> 	at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
> 	at org.wildfly.security.sasl.util.PropertiesSaslClientFactory.createSaslClient(PropertiesSaslClientFactory.java:54)
> 	at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
> 	at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
> 	at org.wildfly.security.sasl.util.FilterMechanismSaslClientFactory.createSaslClient(FilterMechanismSaslClientFactory.java:102)
> 	at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
> 	at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory.createSaslClient(LocalPrincipalSaslClientFactory.java:74)
> 	at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.lambda$createSaslClient$0(PrivilegedSaslClientFactory.java:64)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.createSaslClient(PrivilegedSaslClientFactory.java:64)
> 	at org.wildfly.security.auth.client.AuthenticationConfiguration.createSaslClient(AuthenticationConfiguration.java:1239)
> 	at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.createSaslClient(AuthenticationContextConfigurationClient.java:347)
> 	at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:418)
> 	at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> {noformat}
> which seems to be related to REM3-258.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6949) Upgrade Narayana to
	5.3.4.Final
In-Reply-To: <JIRA.12643164.1471007798000@Atlassian.JIRA>
References: <JIRA.12643164.1471007798000@Atlassian.JIRA>
	<JIRA.12643164.1471007798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643164.1471007798000.90869.1512581239158@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6949:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Upgrade Narayana to 5.3.4.Final
> -------------------------------
>
>                 Key: WFLY-6949
>                 URL: https://issues.jboss.org/browse/WFLY-6949
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 11.0.0.Final
>
>
> https://issues.jboss.org/browse/JBTM/fixforversion/12330712/?selectedTab=com.atlassian.jira.plugins.jira-development-integration-plugin:release-report-tabpanel
> https://github.com/jbosstm/narayana/compare/5.3.3.Final...5.3.4.Final



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7320) LDAP referrals does not work
 - need to set custom filter
In-Reply-To: <JIRA.12655021.1476521835000@Atlassian.JIRA>
References: <JIRA.12655021.1476521835000@Atlassian.JIRA>
	<JIRA.12655021.1476521835000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655021.1476521835000.90877.1512581239386@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7320:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> LDAP referrals does not work - need to set custom filter
> --------------------------------------------------------
>
>                 Key: WFLY-7320
>                 URL: https://issues.jboss.org/browse/WFLY-7320
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 11.0.0.Final
>
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:19 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:19 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7196) The outcome of xa_commit call
 on non exiting transaction is silently ignored
In-Reply-To: <JIRA.12651512.1474554307000@Atlassian.JIRA>
References: <JIRA.12651512.1474554307000@Atlassian.JIRA>
	<JIRA.12651512.1474554307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651512.1474554307000.90888.1512581239875@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7196:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> The outcome of xa_commit call on non exiting transaction is silently ignored
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-7196
>                 URL: https://issues.jboss.org/browse/WFLY-7196
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Tom Ross
>            Assignee: Flavia Rainone
>             Fix For: 11.0.0.Final
>
>
> This is from mail thread on transactional mailing list:
> {noformat}
> There is definitely a bug in EJBR.
> These two at least look wrong by inspection:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/protocol/versionone/XidTransactionPrepareTask.java#L100
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/protocol/versionone/XidTransactionCommitTask.java#L68
> The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it.
> You could simulate this with a test case that gets hold of the EJBR XAResource and invokes:
> xar.prepare(dummyXid) and does not get back XAER_NOTA
> That explains how the root transaction can prepare/commit without error as we can see here:
> 2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext at 18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID at 303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
> 2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext at 18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
> Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions.
> What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue.
> What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently.
> After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7730) Problem in undertow
 application-security-domain removing
In-Reply-To: <JIRA.12665309.1480947295000@Atlassian.JIRA>
References: <JIRA.12665309.1480947295000@Atlassian.JIRA>
	<JIRA.12665309.1480947295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665309.1480947295000.90893.1512581240126@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7730:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Problem in undertow application-security-domain removing
> --------------------------------------------------------
>
>                 Key: WFLY-7730
>                 URL: https://issues.jboss.org/browse/WFLY-7730
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 11.0.0.Final
>
>
> Following error when try to remove *undertow.application-security-domain*:
> {code:java}
>  WFLYCTL0013: Operation ("remove") failed - address: ([
>     ("subsystem" => "undertow"),
>     ("application-security-domain" => "ejb3-tests")
> ]): java.lang.IllegalArgumentException: WFLYCTL0394: Capability 'org.wildfly.extension.undertow.application-security-domain.ejb3-tests' does not provide services of type 'class org.wildfly.security.auth.server.HttpAuthenticationFactory'
> {code}
> Problem is wrong type in obtaining service in RemoveHandler.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6966) FatalError on Transaction
 Expired Entry Monitor during server shutdown
In-Reply-To: <JIRA.12643661.1471423266000@Atlassian.JIRA>
References: <JIRA.12643661.1471423266000@Atlassian.JIRA>
	<JIRA.12643661.1471423266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643661.1471423266000.90900.1512581240403@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6966:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> FatalError on Transaction Expired Entry Monitor during server shutdown
> ----------------------------------------------------------------------
>
>                 Key: WFLY-6966
>                 URL: https://issues.jboss.org/browse/WFLY-6966
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Transactions
>    Affects Versions: 10.1.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Tom Jenkinson
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> I do experience intermittent errors being shown in server log during server shutdown. It happens time to time for server configured to use {{JTS}} transaction that {{Transaction Expired Entry Monitor}} shows {{FatalError}} during container shutdown.
> I do experience this failure when jdbc object store is used.
> The shutdown log looks
> {code}
> 2016-08-16 07:07:46,900 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment wmq.jmsra.rar (runtime-name: wmq.jmsra.rar) in 132ms
> 2016-08-16 07:07:46,914 INFO  [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 2016-08-16 07:07:46,914 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2016-08-16 07:07:46,915 INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> 2016-08-16 07:07:46,921 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2016-08-16 07:07:46,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment crashrecovery-jms-stateless-cmt.jar (runtime-name: crashrecovery-jms-stateless-cmt.jar) in 156ms
> 2016-08-16 07:07:46,947 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 16) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2016-08-16 07:07:46,952 TRACE [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) InputObjectState::InputObjectState(0:ffff7f000001:55f44a88:57b2ec0b:8, Recovery/FactoryContact)
> 2016-08-16 07:07:46,959 INFO  [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 32) AMQ151003: resource adaptor stopped
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) ORB::shutdown ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) OA::destroyRootPOA ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) RootOA::shutdownObject (Servant)
> 2016-08-16 07:07:46,962 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032018: Destroying TransactionManagerService
> 2016-08-16 07:07:46,963 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032014: Stopping transaction recovery manager
> 2016-08-16 07:07:47,000 FATAL [com.arjuna.ats.jts] (Transaction Expired Entry Monitor) ARJUNA022006: The ORB has not been initialized yet
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) Exception in thread "Transaction Expired Entry Monitor" com.arjuna.ats.arjuna.exceptions.FatalError
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.ORBManager.getORB(ORBManager.java:56)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restore_state(FactoryContactItem.java:264)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restoreMe(FactoryContactItem.java:320)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.recreate(FactoryContactItem.java:100)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner.scan(ExpiredContactScanner.java:99)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171)
> 2016-08-16 07:07:47,001 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: Mode <== TERMINATED
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown waiting for scan to end
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan TERMINATED at phase 1
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown scan wait complete
> 2016-08-16 07:07:47,003 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) WFLYJCA0010: Unbound data source [java:jboss/datasources/jdbc-store]
> 2016-08-16 07:07:47,006 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = module_postgresql-9.4.1207.jar
> 2016-08-16 07:07:47,012 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 32) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0.SP16-redhat-1 [023d1e88-638c-11e6-927a-a180c25082cf] stopped
> 2016-08-16 07:07:47,012 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping
> 2016-08-16 07:07:47,018 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 250ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6195) Tests fail on IBM JDK with
 security manager
In-Reply-To: <JIRA.12603702.1455277250000@Atlassian.JIRA>
References: <JIRA.12603702.1455277250000@Atlassian.JIRA>
	<JIRA.12603702.1455277250000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603702.1455277250000.90905.1512581240508@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6195:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Tests fail on IBM JDK with security manager
> -------------------------------------------
>
>                 Key: WFLY-6195
>                 URL: https://issues.jboss.org/browse/WFLY-6195
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Hynek ?v?bek
>            Assignee: Hynek ?v?bek
>             Fix For: 11.0.0.Final
>
>
> *org.jboss.as.test.integration.batch.chunk.ChunkPartitionTestCase#chunks*
> *org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase#definedInMemoryTest*
> *org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase#namedInMemoryTest*
> *org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase#namedJdbcTest*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.batch.chunk.ChunkPartitionTestCase#chunks}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase}}
> Fails with:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component BatchExecutionService for method public javax.batch.runtime.JobExecution org.jboss.as.test.integration.batch.common.BatchExecutionService.start(java.lang.String,java.util.Properties): javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.as.test.integration.batch.common.BatchExecutionService$$$view3.start(Unknown Source)
> 	at org.jboss.as.test.integration.batch.common.StartBatchServlet.doGet(StartBatchServlet.java:65)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	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:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> 	at java.security.AccessController.doPrivileged(AccessController.java:650)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> Caused by: javax.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLInputFactory could not be instantiated: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-defined-in-memory.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at javax.xml.stream.XMLInputFactory.newFactory(Unknown Source)
> 	at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
> 	at org.jberet.job.model.JobParser.parseJob(JobParser.java:48)
> 	at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:97)
> 	at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService.start(BatchExecutionService.java:50)
> 	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 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.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 70 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-defined-in-memory.war/WEB-INF/classes <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.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
> 	at java.lang.System.getProperty(System.java:431)
> 	at java.lang.System.getProperty(System.java:415)
> 	at java.lang.Boolean.getBoolean(Boolean.java:265)
> 	at com.ctc.wstx.api.CommonConfig.<init>(CommonConfig.java:113)
> 	at com.ctc.wstx.api.ReaderConfig.<init>(ReaderConfig.java:482)
> 	at com.ctc.wstx.api.ReaderConfig.createFullDefaults(ReaderConfig.java:533)
> 	at com.ctc.wstx.stax.WstxInputFactory.<init>(WstxInputFactory.java:148)
> 	at sun.reflect.GeneratedConstructorAccessor10.newInstance(Unknown Source)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:436)
> 	at __redirected.__XMLInputFactory.<init>(__XMLInputFactory.java:111)
> 	at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> 	at java.lang.Class.newInstance(Class.java:1924)
> 	at javax.xml.stream.FactoryFinder.newInstance(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	... 103 more
> &amp#27;[0m&amp#27;[31m08:08:10,462 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /batch-defined-in-memory//start: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.as.test.integration.batch.common.BatchExecutionService$$$view3.start(Unknown Source)
> 	at org.jboss.as.test.integration.batch.common.StartBatchServlet.doGet(StartBatchServlet.java:65)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	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:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> 	at java.security.AccessController.doPrivileged(AccessController.java:650)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> Caused by: javax.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLInputFactory could not be instantiated: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-defined-in-memory.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at javax.xml.stream.XMLInputFactory.newFactory(Unknown Source)
> 	at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
> 	at org.jberet.job.model.JobParser.parseJob(JobParser.java:48)
> 	at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:97)
> 	at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService.start(BatchExecutionService.java:50)
> 	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 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.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 70 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-defined-in-memory.war/WEB-INF/classes <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.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
> 	at java.lang.System.getProperty(System.java:431)
> 	at java.lang.System.getProperty(System.java:415)
> 	at java.lang.Boolean.getBoolean(Boolean.java:265)
> 	at com.ctc.wstx.api.CommonConfig.<init>(CommonConfig.java:113)
> 	at com.ctc.wstx.api.ReaderConfig.<init>(ReaderConfig.java:482)
> 	at com.ctc.wstx.api.ReaderConfig.createFullDefaults(ReaderConfig.java:533)
> 	at com.ctc.wstx.stax.WstxInputFactory.<init>(WstxInputFactory.java:148)
> 	at sun.reflect.GeneratedConstructorAccessor10.newInstance(Unknown Source)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:436)
> 	at __redirected.__XMLInputFactory.<init>(__XMLInputFactory.java:111)
> 	at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> 	at java.lang.Class.newInstance(Class.java:1924)
> 	at javax.xml.stream.FactoryFinder.newInstance(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	... 103 more
> {code}
> *org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase#testClientLoginModule*
> *org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase#testSecurityContextAssociation*
> *org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase#testClientLoginModule*
> *org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase#testSecurityContextAssociation*
> {./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase{}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase}}
>  
> Fail with:
> {code}
> javax.ejb.EJBException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "org.jboss.as.ejb3.remote-tx-timeout" "read")" in code source "(vfs:/content/ejb-security-interceptors-test.jar <no signer certificates>)" of "null")
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> 	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:79)
> 	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.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:138)
> 	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.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.ServerSecurityInterceptor.aroundInvoke(ServerSecurityInterceptor.java:108)
> 	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 org.jboss.as.ejb3.component.ContainerInterceptorMethodInterceptorFactory$ContainerInterceptorMethodInterceptor.processInvocation(ContainerInterceptorMethodInterceptorFactory.java:91)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:57)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:254)
> 	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:717)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at java.lang.Thread.getStackTrace(Thread.java:1117)
> 	at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:276)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.ClientSecurityInterceptor.handleInvocationResult(ClientSecurityInterceptor.java:62)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy73.allRoles(Unknown Source)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testMethodAccess(SwitchIdentityTestCase.java:279)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.callUsingSecurityContextAssociation(SwitchIdentityTestCase.java:251)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testSecurityContextAssociation(SwitchIdentityTestCase.java:174)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "org.jboss.as.ejb3.remote-tx-timeout" "read")" in code source "(vfs:/content/ejb-security-interceptors-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.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
> 	at java.lang.System.getProperty(System.java:431)
> 	at java.lang.System.getProperty(System.java:415)
> 	at java.lang.Integer.getInteger(Integer.java:1113)
> 	at java.lang.Integer.getInteger(Integer.java:1069)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.createOrResumeXidTransaction(EJBRemoteTransactionPropagatingInterceptor.java:117)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:71)
> 	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.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:138)
> 	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.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.ServerSecurityInterceptor.aroundInvoke(ServerSecurityInterceptor.java:108)
> 	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 org.jboss.as.ejb3.component.ContainerInterceptorMethodInterceptorFactory$ContainerInterceptorMethodInterceptor.processInvocation(ContainerInterceptorMethodInterceptorFactory.java:91)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:57)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:254)
> 	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:717)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at java.lang.Thread.getStackTrace(Thread.java:1117)
> 	at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> 	at org.jboss.ejb.client.EJBClientInvocationContext$1.run(EJBClientInvocationContext.java:282)
> 	at java.security.AccessController.doPrivileged(AccessController.java:650)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:279)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.ClientSecurityInterceptor.handleInvocationResult(ClientSecurityInterceptor.java:62)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy202.allRoles(Unknown Source)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.BridgeBean.allRoles(BridgeBean.java:55)
> 	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 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:79)
> 	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.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:138)
> 	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.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.ServerSecurityInterceptor.aroundInvoke(ServerSecurityInterceptor.java:108)
> 	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 org.jboss.as.ejb3.component.ContainerInterceptorMethodInterceptorFactory$ContainerInterceptorMethodInterceptor.processInvocation(ContainerInterceptorMethodInterceptorFactory.java:91)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:57)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:254)
> 	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:717)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> {code}
> *org.jboss.as.test.integration.batch.flow.FlowTestCase#flow*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.batch.flow.FlowTestCase#flow}}
> Fails with:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: EJB Invocation failed on component BatchExecutionService for method public javax.batch.runtime.JobExecution org.jboss.as.test.integration.batch.common.BatchExecutionService.start(java.lang.String,java.util.Properties): javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.as.test.integration.batch.common.BatchExecutionService$$$view6.start(Unknown Source)
> 	at org.jboss.as.test.integration.batch.common.StartBatchServlet.doGet(StartBatchServlet.java:65)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	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:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> 	at java.security.AccessController.doPrivileged(AccessController.java:650)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> Caused by: javax.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLInputFactory could not be instantiated: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-flow.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at javax.xml.stream.XMLInputFactory.newFactory(Unknown Source)
> 	at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
> 	at org.jberet.job.model.JobParser.parseJob(JobParser.java:48)
> 	at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:97)
> 	at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService.start(BatchExecutionService.java:50)
> 	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 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.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 70 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-flow.war/WEB-INF/classes <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.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
> 	at java.lang.System.getProperty(System.java:431)
> 	at java.lang.System.getProperty(System.java:415)
> 	at java.lang.Boolean.getBoolean(Boolean.java:265)
> 	at com.ctc.wstx.api.CommonConfig.<init>(CommonConfig.java:113)
> 	at com.ctc.wstx.api.ReaderConfig.<init>(ReaderConfig.java:482)
> 	at com.ctc.wstx.api.ReaderConfig.createFullDefaults(ReaderConfig.java:533)
> 	at com.ctc.wstx.stax.WstxInputFactory.<init>(WstxInputFactory.java:148)
> 	at sun.reflect.GeneratedConstructorAccessor10.newInstance(Unknown Source)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:436)
> 	at __redirected.__XMLInputFactory.<init>(__XMLInputFactory.java:111)
> 	at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> 	at java.lang.Class.newInstance(Class.java:1924)
> 	at javax.xml.stream.FactoryFinder.newInstance(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	... 103 more
> &amp#27;[0m&amp#27;[31m08:08:29,221 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /batch-flow//start: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.as.test.integration.batch.common.BatchExecutionService$$$view6.start(Unknown Source)
> 	at org.jboss.as.test.integration.batch.common.StartBatchServlet.doGet(StartBatchServlet.java:65)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	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:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> 	at java.security.AccessController.doPrivileged(AccessController.java:650)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> Caused by: javax.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLInputFactory could not be instantiated: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-flow.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at javax.xml.stream.XMLInputFactory.newFactory(Unknown Source)
> 	at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
> 	at org.jberet.job.model.JobParser.parseJob(JobParser.java:48)
> 	at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:97)
> 	at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService.start(BatchExecutionService.java:50)
> 	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 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.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 70 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-flow.war/WEB-INF/classes <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.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
> 	at java.lang.System.getProperty(System.java:431)
> 	at java.lang.System.getProperty(System.java:415)
> 	at java.lang.Boolean.getBoolean(Boolean.java:265)
> 	at com.ctc.wstx.api.CommonConfig.<init>(CommonConfig.java:113)
> 	at com.ctc.wstx.api.ReaderConfig.<init>(ReaderConfig.java:482)
> 	at com.ctc.wstx.api.ReaderConfig.createFullDefaults(ReaderConfig.java:533)
> 	at com.ctc.wstx.stax.WstxInputFactory.<init>(WstxInputFactory.java:148)
> 	at sun.reflect.GeneratedConstructorAccessor10.newInstance(Unknown Source)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:436)
> 	at __redirected.__XMLInputFactory.<init>(__XMLInputFactory.java:111)
> 	at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> 	at java.lang.Class.newInstance(Class.java:1924)
> 	at javax.xml.stream.FactoryFinder.newInstance(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	... 103 more
> {code}
> *org.jboss.as.test.integration.web.websocket.WebSocketTestCase#testWebSocket*
> {{mvn clean test -Dsecurity.manager -Dtest=org.jboss.as.test.integration.web.websocket.WebSocketTestCase#testWebSocket}}
> Fails with:
> {code}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "io.undertow.websockets.BIND_ADDRESS" "read")" in code source "(vfs:/content/websocket.war/WEB-INF/classes <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.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
>         at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
>         at java.lang.System.getProperty(System.java:431)
>         at java.lang.System.getProperty(System.java:415)
>         at io.undertow.websockets.client.WebSocketClient$ConnectionBuilder.connect(WebSocketClient.java:229)
>         at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServerInternal(ServerWebSocketContainer.java:440)
>         at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServerInternal(ServerWebSocketContainer.java:434)
>         at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServer(ServerWebSocketContainer.java:194)
>         at org.jboss.as.test.integration.web.websocket.WebSocketTestCase.testWebSocket(WebSocketTestCase.java:52)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:27:20 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8592) Add xts dependency for war
 created by maven in wsat-simple quickstart
In-Reply-To: <JIRA.12688007.1492519576000@Atlassian.JIRA>
References: <JIRA.12688007.1492519576000@Atlassian.JIRA>
	<JIRA.12688007.1492519576000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12688007.1492519576000.90909.1512581240753@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8592:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Add xts dependency for war created by maven in wsat-simple quickstart
> ---------------------------------------------------------------------
>
>                 Key: WFLY-8592
>                 URL: https://issues.jboss.org/browse/WFLY-8592
>             Project: WildFly
>          Issue Type: Bug
>          Components: Quickstarts
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> Creating {{war}} package in {{wsat-simple}} quickstart give a user way to check the functionality of the WS-AT on his own. He can take the war and deploy it on two containers and then invoked the servlet at {{http://localhost:8180/WSATSimpleServletClient}}. But currently, the war fails to be deployed as there is missing {{xts}} dependency in the deployment.
> The Arquillian test passes as there is such dependency added by Shrinkwrap in the test, see
> https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/test/java/org/jboss/as/quickstarts/wsat/simple/ClientIT.java#L45
> {{pom.xml}} should configure the war to contain the {{XTS}} dependency.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7631) Elytron ldap-realm does not
 support recursive role search
In-Reply-To: <JIRA.12662576.1479557636000@Atlassian.JIRA>
References: <JIRA.12662576.1479557636000@Atlassian.JIRA>
	<JIRA.12662576.1479557636000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662576.1479557636000.90917.1512581241035@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7631:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Elytron ldap-realm does not support recursive role search
> ---------------------------------------------------------
>
>                 Key: WFLY-7631
>                 URL: https://issues.jboss.org/browse/WFLY-7631
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 11.0.0.Final
>
>
> Scenario:
> LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process. 
> In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm.
> Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron.  
> See example of LDIF for LDAP server:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4818) WS-RM persistence with
 RMTxStore does not work with JNDI Lookup
In-Reply-To: <JIRA.12575951.1435049731000@Atlassian.JIRA>
References: <JIRA.12575951.1435049731000@Atlassian.JIRA>
	<JIRA.12575951.1435049731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575951.1435049731000.90924.1512581241446@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4818:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> WS-RM persistence with RMTxStore does not work with JNDI Lookup
> ---------------------------------------------------------------
>
>                 Key: WFLY-4818
>                 URL: https://issues.jboss.org/browse/WFLY-4818
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 10.0.0.Alpha3
>            Reporter: Tomas Hofman
>            Assignee: Tomas Hofman
>             Fix For: 11.0.0.Final
>
>
> This is copy of https://bugzilla.redhat.com/show_bug.cgi?id=1223698
> When using reliable messaging feature with RMTxStore, WS calls fail with:
> java.sql.SQLException: You cannot commit with autocommit set!
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcCommit(BaseWrapperManagedConnection.java:1071)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.commit(WrappedConnection.java:758)
> at org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.commit(RMTxStore.java:709)
> at org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.removeSourceSequence(RMTxStore.java:495)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:21 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:21 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7071) Changing default-realm of
 Elytron security-domain through CLI can put the server configuration to
 wrong state
In-Reply-To: <JIRA.12649230.1473311370000@Atlassian.JIRA>
References: <JIRA.12649230.1473311370000@Atlassian.JIRA>
	<JIRA.12649230.1473311370000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649230.1473311370000.90935.1512581241819@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7071:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7071
>                 URL: https://issues.jboss.org/browse/WFLY-7071
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>             Fix For: 11.0.0.Final
>
>
> Values of write-attribute operation for default-realm of Elytron security-domain are not checked. It means that CLI allows users to set application server to wrong state. The same happens if realm, which is considered as default-realm, is removed from used security-domain realms. CLI should deny write attribute operation with wrong value (in the same way as it works for another security-domain attributes).
> After reload, server is not started and following logs occur in console:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 25) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("security-domain" => "ApplicationDomain")
> ]) - failure description: "WFLYELY00013: The default_realm 'WrongRealm' is not in the list or realms referenced by this domain."
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem elytron boot operations"
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem elytron boot operations\""
> FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6796) Upgrade Weld to 2.3.5.Final
In-Reply-To: <JIRA.12636541.1467360888000@Atlassian.JIRA>
References: <JIRA.12636541.1467360888000@Atlassian.JIRA>
	<JIRA.12636541.1467360888000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12636541.1467360888000.90940.1512581242160@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6796:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Upgrade Weld to 2.3.5.Final
> ---------------------------
>
>                 Key: WFLY-6796
>                 URL: https://issues.jboss.org/browse/WFLY-6796
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: CDI / Weld
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 11.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:22 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:22 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6193) CustomProviderPreferenceTest
 fails due to ReflectPermission
In-Reply-To: <JIRA.12603696.1455275911000@Atlassian.JIRA>
References: <JIRA.12603696.1455275911000@Atlassian.JIRA>
	<JIRA.12603696.1455275911000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603696.1455275911000.90947.1512581242797@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6193:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> CustomProviderPreferenceTest fails due to ReflectPermission
> -----------------------------------------------------------
>
>                 Key: WFLY-6193
>                 URL: https://issues.jboss.org/browse/WFLY-6193
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Hynek ?v?bek
>            Assignee: Ivo Studensky
>             Fix For: 11.0.0.Final
>
>
> *org.jboss.as.test.integration.jaxrs.provider.preference.CustomProviderPreferenceTest#testCustomMessageBodyWriterIsUsed*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxrs.provider.preference.CustomProviderPreferenceTest#testCustomMessageBodyWriterIsUsed}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-100) UT005023: Exception handling request to /providers/api/user: org.jboss.resteasy.spi.UnhandledException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/providers.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)
> 	at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	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:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	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.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/providers.war/WEB-INF/classes <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.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
> 	at org.jboss.resteasy.core.PropertyInjectorImpl.populateMap(PropertyInjectorImpl.java:69)
> 	at org.jboss.resteasy.core.PropertyInjectorImpl.<init>(PropertyInjectorImpl.java:54)
> 	at org.jboss.resteasy.cdi.JaxrsInjectionTarget.getPropertyInjector(JaxrsInjectionTarget.java:102)
> 	at org.jboss.resteasy.cdi.JaxrsInjectionTarget.inject(JaxrsInjectionTarget.java:50)
> 	at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
> 	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.as.test.integration.jaxrs.provider.preference.Resource$Proxy$_$$_WeldClientProxy.getUser(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.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> 	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:395)
> 	... 34 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:27:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6174) Upgrade Weld to 2.3.3.Final
In-Reply-To: <JIRA.12603497.1455183541000@Atlassian.JIRA>
References: <JIRA.12603497.1455183541000@Atlassian.JIRA>
	<JIRA.12603497.1455183541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603497.1455183541000.90953.1512581243016@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6174:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Upgrade Weld to 2.3.3.Final
> ---------------------------
>
>                 Key: WFLY-6174
>                 URL: https://issues.jboss.org/browse/WFLY-6174
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: CDI / Weld
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 11.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4590) l1-lifespan attribute in
 distributed cache configuration does not enable l1 cache
In-Reply-To: <JIRA.12570744.1430834535000@Atlassian.JIRA>
References: <JIRA.12570744.1430834535000@Atlassian.JIRA>
	<JIRA.12570744.1430834535000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570744.1430834535000.90960.1512581243421@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-4590:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> l1-lifespan attribute in distributed cache configuration does not enable l1 cache
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-4590
>                 URL: https://issues.jboss.org/browse/WFLY-4590
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1
>            Reporter: Dominik Pospisil
>            Assignee: Dominik Pospisil
>             Fix For: 11.0.0.Final
>
>
> l1-lifespan attribute in distributed cache configuration is not honored. If set to a non-zero value it just sets the underlying cache config parameter, but does not explicitly enable l1 which is by default disabled.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8362) upgrade jboss-ejb-client to
	4.0.0.Beta20
In-Reply-To: <JIRA.12681912.1489526527000@Atlassian.JIRA>
References: <JIRA.12681912.1489526527000@Atlassian.JIRA>
	<JIRA.12681912.1489526527000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12681912.1489526527000.90964.1512581243531@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8362:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> upgrade jboss-ejb-client to 4.0.0.Beta20
> ----------------------------------------
>
>                 Key: WFLY-8362
>                 URL: https://issues.jboss.org/browse/WFLY-8362
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Application Client, EJB
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 11.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:23 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8026) read-resource operation of
 jaxrs subsystem doesn't work if HttpServletDispatcher is used
In-Reply-To: <JIRA.12674922.1486154214000@Atlassian.JIRA>
References: <JIRA.12674922.1486154214000@Atlassian.JIRA>
	<JIRA.12674922.1486154214000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674922.1486154214000.90970.1512581243819@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8026:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> read-resource operation of jaxrs subsystem doesn't work if HttpServletDispatcher is used
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-8026
>                 URL: https://issues.jboss.org/browse/WFLY-8026
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 10.1.0.Final
>            Reporter: R Searls
>            Assignee: R Searls
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> There are a set of "Bootstap" classes which when present in the web.xml file require
> jaxrs (i.e. resteasy) components to be configured using Resteasy Configuration Switches.
> (see https://docs.jboss.org/resteasy/docs/3.0.4.Final/userguide/html/Installation_Configuration.html#d4e125 )
> Adding the following switch to the web.xml should solve the issue. 
> 2 resteasy config switches need to be added dynamically when a jaxrs Application subclass  is found in the web.xml file.  
> This addresses the issue flagged in https://issues.jboss.org/browse/JBEAP-8064



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8176) CS tool,
 --salt and --iteration parameters unintentionally required
In-Reply-To: <JIRA.12678092.1487683426000@Atlassian.JIRA>
References: <JIRA.12678092.1487683426000@Atlassian.JIRA>
	<JIRA.12678092.1487683426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678092.1487683426000.90978.1512581244015@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8176:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> CS tool, --salt and --iteration parameters unintentionally required
> -------------------------------------------------------------------
>
>                 Key: WFLY-8176
>                 URL: https://issues.jboss.org/browse/WFLY-8176
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Peter Skopek
>            Priority: Blocker
>              Labels: credential-store
>             Fix For: 11.0.0.Final
>
>
> Any command have to contain --salt and --iteration parameters to be sucessfull, otherwise NPE occures. However this parameters are necesarry only in margin case
> {code}
> [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary
> Exception in thread "main" java.lang.NullPointerException
> 	at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
> 	at java.util.regex.Matcher.reset(Matcher.java:309)
> 	at java.util.regex.Matcher.<init>(Matcher.java:229)
> 	at java.util.regex.Pattern.matcher(Pattern.java:1093)
> 	at java.util.Formatter.parse(Formatter.java:2547)
> 	at java.util.Formatter.format(Formatter.java:2501)
> 	at java.io.PrintStream.format(PrintStream.java:970)
> 	at java.io.PrintStream.printf(PrintStream.java:871)
> 	at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58)
> {code}
> with these parameters command success
> {code}
> [mchoma at localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt 12345678 --iteration 230
> Alias "myalias" has been successfully stored
> Credential store command summary:
> --------------------------------------
> /subsystem=elytron/credential-store=test:add(uri="cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="MASK-uNWeyrmbByBEjgZM1FAPQW==;12345678;230"})
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8983) ReplicatedJournal class -
 disabled trace logging
In-Reply-To: <JIRA.12698597.1498122613000@Atlassian.JIRA>
References: <JIRA.12698597.1498122613000@Atlassian.JIRA>
	<JIRA.12698597.1498122613000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12698597.1498122613000.90984.1512581244167@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8983:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> ReplicatedJournal class - disabled trace logging
> ------------------------------------------------
>
>                 Key: WFLY-8983
>                 URL: https://issues.jboss.org/browse/WFLY-8983
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Romain Pelisse
>            Assignee: Romain Pelisse
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> There is disabled logging of {{ReplicatedJournal}} due to hardcoded value:
> {code}
> private static final boolean trace = false;
> {code}
> Every trace log can never be logged:
> {code}
> if (ReplicatedJournal.trace) {
>          ReplicatedJournal.trace("Append record id = " + id + " recordType = " + recordType);
>       }
> {code}
> This is not ideal for investivatigation purposes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6177) WF 10 documentation
 references CDI 1.0 spec
In-Reply-To: <JIRA.12603581.1455200294000@Atlassian.JIRA>
References: <JIRA.12603581.1455200294000@Atlassian.JIRA>
	<JIRA.12603581.1455200294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603581.1455200294000.90989.1512581244280@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6177:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> WF 10 documentation references CDI 1.0 spec
> -------------------------------------------
>
>                 Key: WFLY-6177
>                 URL: https://issues.jboss.org/browse/WFLY-6177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation
>            Reporter: Tomas Remes
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>
> It is referenced at https://docs.jboss.org/author/display/WFLY10/CDI+Reference. In fact WF 10 includes CDI 1.2. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6620) Remove typo from BAControler
 interface and its implementations
In-Reply-To: <JIRA.12626437.1463492043000@Atlassian.JIRA>
References: <JIRA.12626437.1463492043000@Atlassian.JIRA>
	<JIRA.12626437.1463492043000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626437.1463492043000.90997.1512581244468@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6620:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Remove typo from BAControler interface and its implementations
> --------------------------------------------------------------
>
>                 Key: WFLY-6620
>                 URL: https://issues.jboss.org/browse/WFLY-6620
>             Project: WildFly
>          Issue Type: Task
>          Components: XTS
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5499) Channel end notification
 received, closing channel ... should be logged at debug in EjbLogger
In-Reply-To: <JIRA.12588317.1444372587000@Atlassian.JIRA>
References: <JIRA.12588317.1444372587000@Atlassian.JIRA>
	<JIRA.12588317.1444372587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588317.1444372587000.91002.1512581244594@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5499:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Channel end notification received, closing channel ... should be logged at debug in EjbLogger
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5499
>                 URL: https://issues.jboss.org/browse/WFLY-5499
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Naming
>            Reporter: Takayuki Konishi
>             Fix For: 11.0.0.Final
>
>
> Remote naming is logging this at ERROR, though it seems normal and no adverse effects are apparent, we should log it at debug instead of error.
> {code}
> ERROR [org.jboss.as.ejb3] (Remoting "master at ap02:server-apip" task-2) JBAS014141: Channel end notification received, closing channel Channel ID 6b8f00d7 (inbound) of Remoting connection 36e4f81b to /192.168.1.10:64354
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:24 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:24 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3978) PicketLink Subsystem EAP 6.4
	Issues
In-Reply-To: <JIRA.12555132.1413297335000@Atlassian.JIRA>
References: <JIRA.12555132.1413297335000@Atlassian.JIRA>
	<JIRA.12555132.1413297335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555132.1413297335000.91011.1512581244899@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3978:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> PicketLink Subsystem EAP 6.4 Issues
> -----------------------------------
>
>                 Key: WFLY-3978
>                 URL: https://issues.jboss.org/browse/WFLY-3978
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>             Fix For: 11.0.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6727) Transaction resource
 definition missing validator for default timeout
In-Reply-To: <JIRA.12632307.1466002552000@Atlassian.JIRA>
References: <JIRA.12632307.1466002552000@Atlassian.JIRA>
	<JIRA.12632307.1466002552000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12632307.1466002552000.91017.1512581245084@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6727:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Transaction resource definition missing validator for default timeout
> ---------------------------------------------------------------------
>
>                 Key: WFLY-6727
>                 URL: https://issues.jboss.org/browse/WFLY-6727
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 10.0.0.Final
>            Reporter: Michal Petrov
>            Assignee: Michal Petrov
>            Priority: Minor
>             Fix For: 11.0.0.Final
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> {{TransactionSubsystemRootResourceDefinition}} is missing a validator for {{default-timeout}}. This affects web console when something bigger than a 32-bit integer is entered. I see no specification but I'm assuming (0,MAX_INT) is the expected range.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6402) EJBs accessible too early
	(spec violation)
In-Reply-To: <JIRA.12610975.1458232655000@Atlassian.JIRA>
References: <JIRA.12610975.1458232655000@Atlassian.JIRA>
	<JIRA.12610975.1458232655000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610975.1458232655000.91027.1512581245360@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6402:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> EJBs accessible too early (spec violation)
> ------------------------------------------
>
>                 Key: WFLY-6402
>                 URL: https://issues.jboss.org/browse/WFLY-6402
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Fedor Gavrilov
>              Labels: downstream_dependency
>             Fix For: 11.0.0.Final
>
>         Attachments: auto-test-reproducer.zip
>
>
> {code}
> EJB 3.1 spec, section 4.8.1:
>     "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application.
> {code}
> Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call.
> This Jira ticket handles two PR's on WFLY:
> https://github.com/wildfly/wildfly/pull/8824 (that is already merged)
> and https://github.com/wildfly/wildfly/pull/8989



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6142) [Migration]
 StuckThreadDetectionValve is not automatically migrated
In-Reply-To: <JIRA.12603036.1454946189000@Atlassian.JIRA>
References: <JIRA.12603036.1454946189000@Atlassian.JIRA>
	<JIRA.12603036.1454946189000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603036.1454946189000.91033.1512581245480@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-6142:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> [Migration] StuckThreadDetectionValve is not automatically migrated
> -------------------------------------------------------------------
>
>                 Key: WFLY-6142
>                 URL: https://issues.jboss.org/browse/WFLY-6142
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>             Fix For: 11.0.0.Final
>
>
> {{org.apache.catalina.valves.StuckThreadDetectionValve}} is not automatically migrated even though there exists equivalent handler in EAP7 ({{io.undertow.server.handlers.StuckThreadDetectionHandler}}).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:25 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:25 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7097) The constant-role-mapper is
 not able to handle role name with space in it
In-Reply-To: <JIRA.12649888.1473756125000@Atlassian.JIRA>
References: <JIRA.12649888.1473756125000@Atlassian.JIRA>
	<JIRA.12649888.1473756125000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649888.1473756125000.91043.1512581245721@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7097:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> The constant-role-mapper is not able to handle role name with space in it
> -------------------------------------------------------------------------
>
>                 Key: WFLY-7097
>                 URL: https://issues.jboss.org/browse/WFLY-7097
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Final
>
>
> Adding a role with a space in the name results in 2 roles (for parts of the name) added. The problem is visible after server reload. E.g. adding role "JBoss Admin" results in 2 roles assigned "JBoss" and "Admin"
> *Expected behavior*
> Spaces in role name must be supported and correctly handled. E.g. After adding "JBoss Admin" and server reload "JBoss Admin" is assigned.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7317) Elytron ldap-key-store DMR
 XSD inconsistency
In-Reply-To: <JIRA.12654928.1476449660000@Atlassian.JIRA>
References: <JIRA.12654928.1476449660000@Atlassian.JIRA>
	<JIRA.12654928.1476449660000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654928.1476449660000.91051.1512581246037@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7317:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Elytron ldap-key-store DMR XSD inconsistency 
> ---------------------------------------------
>
>                 Key: WFLY-7317
>                 URL: https://issues.jboss.org/browse/WFLY-7317
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>              Labels: user_experience
>             Fix For: 11.0.0.Final
>
>
> * in XSD there are missing attributes {{key-attribute}} and {{key-type}}
> * in XSD {{value}} attribute of {{new-item-template}} is not a list type as in DMR
> * in DMR {{name}} in {{new-item-attributes}} is optional. In XSD it is marked as required. Should be required in DMR as well.
> * synchronize documenation of XSD and DMR. Documentation in XSD seems little bit detailed.
> * In {{certificate-type}} and {{certificate-attribute}} probably remove link to oracle java 8 documentation. I consider it usefull, but I see couple of maintaining issues. Link can change. Java 9 is comming and can have own enumaration. We also support IBM java. Just stating "For possible values see java documentation of CertificateFactory/CertPathEncodings" would be enough here



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3809) JDR incorrectly sets
 JBOSS_HOME path name in the jar file on Windows
In-Reply-To: <JIRA.12551043.1409781442000@Atlassian.JIRA>
References: <JIRA.12551043.1409781442000@Atlassian.JIRA>
	<JIRA.12551043.1409781442000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12551043.1409781442000.91056.1512581246206@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3809:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> JDR incorrectly sets JBOSS_HOME path name in the jar file on Windows
> --------------------------------------------------------------------
>
>                 Key: WFLY-3809
>                 URL: https://issues.jboss.org/browse/WFLY-3809
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>         Environment: All modes on Windows
>            Reporter: Jesse Jaggars
>            Assignee: Jesse Jaggars
>             Fix For: 11.0.0.Final
>
>
> JDR replaces $JBOSS_HOME with the text `JBOSS_HOME` in the generated zipfile. On windows the path is improperly constructed. For example if JBOSS_HOME=/foo/bar/baz, when the file /foo/bar/baz/example.txt is copied into the JDR archive the path will be:
> JBOSS_HOMEz/example.txt
> It should be:
> JBOSS_HOME/example.txt



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8186) CS tool,
 can't list --help without NPE occurence
In-Reply-To: <JIRA.12678231.1487749600000@Atlassian.JIRA>
References: <JIRA.12678231.1487749600000@Atlassian.JIRA>
	<JIRA.12678231.1487749600000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678231.1487749600000.91064.1512581246406@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-8186:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> CS tool, can't list --help without NPE occurence
> ------------------------------------------------
>
>                 Key: WFLY-8186
>                 URL: https://issues.jboss.org/browse/WFLY-8186
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Peter Skopek
>            Priority: Critical
>              Labels: credential-store
>             Fix For: 11.0.0.Final
>
>
> {code}
> java -jar wildfly-elytron-tool.jar credential-store -h 
> {code}
> or because of WFLY-8176
> {code}
> java -jar wildfly-elytron-tool.jar credential-store -h --salt 12345678 --iteration 230
> {code}
> leads to 
> {code}
> usage: java -jar wildfly-elytron-tool.jar credential-store <sub-command>
>        <options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c]  [-f]  [-i
>        <arg>] [-l <arg>] [-p <arg>]  [-s <arg>] [-t <arg>] [-u <arg>]  [-x
>        <arg>]
> Exception in thread "main" java.lang.NullPointerException
>     at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
>     at java.util.regex.Matcher.reset(Matcher.java:309)
>     at java.util.regex.Matcher.<init>(Matcher.java:229)
>     at java.util.regex.Pattern.matcher(Pattern.java:1093)
>     at java.util.Formatter.parse(Formatter.java:2547)
>     at java.util.Formatter.format(Formatter.java:2501)
>     at java.io.PrintStream.format(PrintStream.java:970)
>     at java.io.PrintStream.printf(PrintStream.java:871)
>     at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:58)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:26 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:26 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7067) show-resources operation of
 jaxrs subsystem is unable to read jax-rs end-point from subresources
In-Reply-To: <JIRA.12649074.1473235957000@Atlassian.JIRA>
References: <JIRA.12649074.1473235957000@Atlassian.JIRA>
	<JIRA.12649074.1473235957000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649074.1473235957000.91070.1512581246764@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7067:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> show-resources operation of jaxrs subsystem is unable to read jax-rs end-point from subresources
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7067
>                 URL: https://issues.jboss.org/browse/WFLY-7067
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>             Fix For: 11.0.0.Final
>
>
> Show-resources operation of jaxrs subsystem is unable to read jax-rs end-point from subresources.
> Example:
> {code:java}
> @Path("/root")
> public class Root {
>     @Path("/method")
>     public Sub rootMethod() {
>         return new Sub();
>     }
> }
> {code}
> {code:java}
> public class Sub {
>     @GET
>     @Path("submethod")
>     public String returnValue() {
>         return "555";
>     }
> }
> {code}
> {noformat}
> [standalone at localhost:9990 /] /deployment=jaxrs-wf.war/subsystem=jaxrs:show-resources
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.ClassCastException: org.jboss.resteasy.core.ResourceLocatorInvoker cannot be cast to org.jboss.resteasy.core.ResourceMethodInvoker",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] 
> {noformat}
> {noformat}
> 15:52:04,618 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 33) WFLYCTL0013: Operation ("show-resources") failed - address: ([
>     ("deployment" => "jaxrs-wf.war"),
>     ("subsystem" => "jaxrs")
> ]): java.lang.ClassCastException: org.jboss.resteasy.core.ResourceLocatorInvoker cannot be cast to org.jboss.resteasy.core.ResourceMethodInvoker
> 	at org.jboss.as.jaxrs.JaxrsDeploymentDefinition$ShowJaxrsResourcesHandler.handle(JaxrsDeploymentDefinition.java:107)
> 	at org.jboss.as.jaxrs.JaxrsDeploymentDefinition$ShowJaxrsResourcesHandler$1.execute(JaxrsDeploymentDefinition.java:163)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	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:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:34:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7524) Add Hibernate-Spatial to
 WildFly Feature Pack
In-Reply-To: <JIRA.12660230.1478620902000@Atlassian.JIRA>
References: <JIRA.12660230.1478620902000@Atlassian.JIRA>
	<JIRA.12660230.1478620902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660230.1478620902000.91146.1512581640511@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7524:
-----------------------------
    Fix Version/s:     (was: 10.x.x TBD)


Resetting the fix version as it is still open and 10.0.0.TBD was a long time ago. If it should be resolved, please do so (and close) against the relevant fix version

> Add Hibernate-Spatial to WildFly Feature Pack
> ---------------------------------------------
>
>                 Key: WFLY-7524
>                 URL: https://issues.jboss.org/browse/WFLY-7524
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 10.1.0.Final
>         Environment: Linux / OpenJDK 8 / WildFly 10.1.0.Final
>            Reporter: Dennis Gesker
>            Assignee: Jason Greene
>              Labels: wildfly-feature-pack
>
> If possible kindly add jars need to make use of hibernate-spatial to WildFly-Feature-Pack
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> BTW, thank you for this package. It saves a HUGE amount of time with dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:35:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7036) Add MQTT protocol support for
	JMS
In-Reply-To: <JIRA.12648543.1472936376000@Atlassian.JIRA>
References: <JIRA.12648543.1472936376000@Atlassian.JIRA>
	<JIRA.12648543.1472936376000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648543.1472936376000.91153.1512581700414@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7036:
-----------------------------
    Fix Version/s:     (was: 10.x.x TBD)


Resetting the fix version as it is still open and 10.0.0.TBD was a long time ago. If it should be resolved, please do so (and close) against the relevant fix version

> Add MQTT protocol support for JMS
> ---------------------------------
>
>                 Key: WFLY-7036
>                 URL: https://issues.jboss.org/browse/WFLY-7036
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Juraj Veverka
>            Assignee: Jeff Mesnil
>
> It would be great if MQTT protocol is supported by JMS subsystem in WildFly AS. As of WildFly 10, ActiveMQ is used as JMS implementation in WildFly AS. ActiveMQ supports MQTT protocol, but if I try to add remote-acceptor in <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
>                 <remote-acceptor name="netty-acceptor-mqtt" socket-binding="messaging-mqtt">
>                     <param name="protocols" value="MQTT,CORE"/>
>                 </remote-acceptor>
> When WildFly is started, I can see following log statement:
> 22:55:48,487 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 64) AMQ221020: Started Acceptor at 127.0.0.1:7998 for protocols [CORE,AMQP,HORNETQ,STOMP]
> which means that MQTT protocol is not supportred, instead CORE,AMQP,HORNETQ,STOMP are activated.
> MQTT is used by IoT devices, it would be nice if WildFly 10.2.0 AS has out-of-the-box support.  



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:35:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 6 Dec 2017 12:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2167) Implement stacked rule unit
	invocations
In-Reply-To: <JIRA.12723814.1512577252000@Atlassian.JIRA>
References: <JIRA.12723814.1512577252000@Atlassian.JIRA>
	<JIRA.12723814.1512577252000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723814.1512577252000.91155.1512581700496@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2167:
--------------------------------
    Sprint: 2017 Week 49-50


> Implement stacked rule unit invocations
> ---------------------------------------
>
>                 Key: DROOLS-2167
>                 URL: https://issues.jboss.org/browse/DROOLS-2167
>             Project: Drools
>          Issue Type: Feature Request
>          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 Dec  6 12:36:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3582) Redesign mod_cluster xml
	subsystem parsers
In-Reply-To: <JIRA.12545570.1404405485000@Atlassian.JIRA>
References: <JIRA.12545570.1404405485000@Atlassian.JIRA>
	<JIRA.12545570.1404405485000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545570.1404405485000.91160.1512581760369@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3582:
-----------------------------
    Fix Version/s:     (was: 10.x.x TBD)


Resetting the fix version as it is still open and 10.0.0.TBD was a long time ago. If it should be resolved, please do so (and close) against the relevant fix version

> Redesign mod_cluster xml subsystem parsers
> ------------------------------------------
>
>                 Key: WFLY-3582
>                 URL: https://issues.jboss.org/browse/WFLY-3582
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> As per https://github.com/wildfly/wildfly/pull/6449



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:37:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2100) Vault.sh logging improvements
In-Reply-To: <JIRA.12500866.1379443771000@Atlassian.JIRA>
References: <JIRA.12500866.1379443771000@Atlassian.JIRA>
	<JIRA.12500866.1379443771000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500866.1379443771000.91176.1512581820687@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2100:
-----------------------------
    Fix Version/s:     (was: 10.x.x TBD)


Resetting the fix version as it is still open and 10.0.0.TBD was a long time ago. If it should be resolved, please do so (and close) against the relevant fix version

> Vault.sh logging improvements
> -----------------------------
>
>                 Key: WFLY-2100
>                 URL: https://issues.jboss.org/browse/WFLY-2100
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chris Dolphy
>            Assignee: Peter Skopek
>
> Several errors with vault.sh (ineractive Vault Tool) do not display enough information to debug.    
> For example, "Exception occurred:PBOX000128: Unable to encrypt data".  It would be nice if there was some way to see the cause of this exception either with additional logging options, a verbose option or by default.  This one is caused by VaultInteraction.java only displaying the localized error message of the exception.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:37:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-264) Add support for
 use1PcForAutoCommitTransactions
In-Reply-To: <JIRA.12464799.1335208150000@Atlassian.JIRA>
References: <JIRA.12464799.1335208150000@Atlassian.JIRA>
	<JIRA.12464799.1335208150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464799.1335208150000.91182.1512581820798@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-264:
----------------------------
    Fix Version/s:     (was: 10.x.x TBD)


Resetting the fix version as it is still open and 10.0.0.TBD was a long time ago. If it should be resolved, please do so (and close) against the relevant fix version

> Add support for use1PcForAutoCommitTransactions
> -----------------------------------------------
>
>                 Key: WFLY-264
>                 URL: https://issues.jboss.org/browse/WFLY-264
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> Since clustered web sessions/SFSBs won't ever incur inter-node concurrent access, we can tolerate a 1PC commit optimization - which will reduce the number of RPCs involved in replication/distribution.  This should result it a significant performance gains for REPL_SYNC and DIST_SYNC caches.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:37:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7209) Operation to list installed
 Resource Adapters
In-Reply-To: <JIRA.12651854.1474714280000@Atlassian.JIRA>
References: <JIRA.12651854.1474714280000@Atlassian.JIRA>
	<JIRA.12651854.1474714280000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651854.1474714280000.91189.1512581820939@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7209:
-----------------------------
    Fix Version/s:     (was: 10.1.0.Final)


> Operation to list installed Resource Adapters
> ---------------------------------------------
>
>                 Key: WFLY-7209
>                 URL: https://issues.jboss.org/browse/WFLY-7209
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Guillermo Gonz?lez de Ag?ero
>            Assignee: Stefano Maestri
>         Attachments: 1-jdbc.png, 2-ra.png
>
>
> Currently there's no way to list all the deployed Resource Adapters (modules or deployed archives). I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers (see attached screenshots). This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 12:38:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5454) Protocol showing as http
 instead of https on wsdl when web service is configured to run on secure
 port 8443
In-Reply-To: <JIRA.12586997.1443775447000@Atlassian.JIRA>
References: <JIRA.12586997.1443775447000@Atlassian.JIRA>
	<JIRA.12586997.1443775447000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586997.1443775447000.91195.1512581880228@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-5454:
-----------------------------
    Fix Version/s:     (was: 8.2.0.Final)


Resetting the fix version as it is still open and 8.2.0.Final was a long time ago. If it should be resolved, please do so (and close) against the relevant fix version

> Protocol showing as http instead of https on wsdl when web service is configured to run on secure port 8443
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5454
>                 URL: https://issues.jboss.org/browse/WFLY-5454
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Services
>    Affects Versions: 8.2.0.Final
>            Reporter: Obakeng Balatseng
>            Assignee: Alessio Soldano
>            Priority: Minor
>
> On the web service subsystem both the wsdl port and wsdl-secure-port are configured to 8443
> <wsdl-port>8443</wsdl-port>
> <wsdl-secure-port>8443</wsdl-secure-port>
> But when the wsdl is advertised on the frontend, the protocol on the wsdl address is always as http instead of https.
> For example, http://localhost:8443/magnificent-service/Verify?wsdl



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:39:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3434) Add xsd schemas on wildlfy.org
In-Reply-To: <JIRA.12542582.1401743975000@Atlassian.JIRA>
References: <JIRA.12542582.1401743975000@Atlassian.JIRA>
	<JIRA.12542582.1401743975000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542582.1401743975000.91200.1512581940226@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3434:
-----------------------------
    Fix Version/s:     (was: No Release)


> Add xsd schemas on wildlfy.org
> ------------------------------
>
>                 Key: WFLY-3434
>                 URL: https://issues.jboss.org/browse/WFLY-3434
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Tomaz Cerar
>
> we should have all wildfly releated schemas to wildfly.org/schema.
> As part of this task, we need to update all docs to point to new URL.
> have as much automated as possible process for uploading new schemas when new releases is done.
> consolidate this over various (sub)projects that provide schemas that should be here.
> What is not expected to be done is to host all old schemas that have nothing do do with WildFly on new location. 
> Example are most of pre AS7 jboss specific descriptors that WildFly no longer honors.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 13:09:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 6 Dec 2017 13:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.91271.1512583740506@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502622#comment-13502622 ] 

Darran Lofthouse commented on ELY-1455:
---------------------------------------

Thanks for the SQL although I don't think the second table is the one you are currently using?  From the attached config you seem to be referencing a table called 'user_role_auth'.

But overall anything to simplify the reproducer down to the bare minimum needed to reproduce the issue would be appreciated, the less pieces in the test to reproduce the better so we don't need to be distracted by unrelated technologies.  Also could you please show your latest configuration?  I believe you have now removed SSO and still experience the same error?

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 13:19:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 6 Dec 2017 13:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.91309.1512584340216@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502623#comment-13502623 ] 

Darran Lofthouse commented on ELY-1455:
---------------------------------------

I have been able to make some changes and I think I can reproduce with what we have so far.


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 13:28:00 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Wed, 6 Dec 2017 13:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.91344.1512584880318@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alberto Gori updated ELY-1455:
------------------------------
    Attachment: elytron-bug.zip


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, elytron-bug.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 13:32:00 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Wed, 6 Dec 2017 13:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.91370.1512585120827@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502627#comment-13502627 ] 

Alberto Gori commented on ELY-1455:
-----------------------------------

I have uploaded everything again. zip file contains sources and aside the pom you can also find profile and keystore used for single sign on (so it's still enabled).

As for the table, you don't need the second table anymore if you use latest profile. USER is what you need.

*Could you please delete wmt-elytron.war and elytron-bug-src.zip? They contain sensitive information and password...my mistake! :/ *

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, elytron-bug.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 13:53:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 6 Dec 2017 13:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.91434.1512586380497@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502636#comment-13502636 ] 

Darran Lofthouse commented on ELY-1455:
---------------------------------------

Debugging this I can see we do actually have two bugs that are contributing to the issue you are experiencing.

# Where the JDBC realm loads an identity it should be caching the results of the queries for the duration of that HTTP request, so after the principalQuery has been executed it should retain this,  This is not happening so it is executing the query twice within a single authentication attempt.
# Although the web application is configured to use FORM authentication it appears to be mapped to /account/login rather than j_security_check so instead of using the FORM authentication mechanism it is using the programmatic authentication API on HttpServletRequest - this method has a bug in that it is caching the username and restoring it rather than the resulting SecurityIdentity.

I am going to work on both of these issues now as they are genuine issues that do require a fix but I think in light of this there are a couple of options: -

# Update the login page to submit to j_security_check this will mean the SecurityIdentity caching of the FORM authentication mechanism will kick in properly.
# Insert an in-memory cache in front of the JDBC security realm, this will cache the first interaction with the realm so for subsequent requests the realm and the database will not be hit.

The following CLI commands enable the cache: -

{noformat}
[standalone at localhost:9990 /] batch 
[standalone at localhost:9990 / #] ./subsystem=elytron/caching-realm=jdbc-cache:add(realm=wmtRealm)
[standalone at localhost:9990 / #] ./subsystem=elytron/security-domain=wmtSD:write-attribute(name=default-realm, value=jdbc-cache)
[standalone at localhost:9990 / #] ./subsystem=elytron/security-domain=wmtSD:write-attribute(name=realms, value=[{realm=jdbc-cache, role-decoder=groups-to-roles}])
[standalone at localhost:9990 / #] run-batch 
{noformat}

This explains the back and forth we had early on discussing this where the logs did not quite make sense, I understand now that the FormAuthenticationMechanism was serving up the login page but now I can see it was not being used for the subsequent authentication which is where the messages I was expecting to see in the log were going missing.





>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         Attachments: elytron-bug-src.zip, elytron-bug.zip, server.log, standalone-full-ha.xml, wmt-elytron.war
>
>
> 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  Wed Dec  6 13:59:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 6 Dec 2017 13:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.91454.1512586741457@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1455:
----------------------------------
    Attachment:     (was: elytron-bug-src.zip)


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         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  Wed Dec  6 13:59:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 6 Dec 2017 13:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.91464.1512586741871@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1455:
----------------------------------
    Attachment:     (was: wmt-elytron.war)


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         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  Wed Dec  6 14:05:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Dec 2017 14:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.91485.1512587100268@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502639#comment-13502639 ] 

Brian Stansberry commented on WFCORE-887:
-----------------------------------------

Analysis of the current (master) WildFly management API using the hal/model-graph[1] tool shows the following attributes that are credential references but also support expressions:

{code}
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"r.address"                                                           ?"a.name"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/core-service=management/management-interface=http-interf?"interface"                  ?
?ace"                                                                  ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/core-service=management/management-interface=native-inte?"interface"                  ?
?rface"                                                                ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*"                                 ?"default-interface"          ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/local-destination-outbound-socket?"socket-binding-ref"         ?
?-binding=*"                                                           ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/local-destination-outbound-socket?"source-interface"           ?
?-binding=*"                                                           ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/remote-destination-outbound-socke?"source-interface"           ?
?t-binding=*"                                                          ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/socket-binding=*"                ?"interface"                  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=mail/mail-session=*/custom=*"                   ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=remoting/local-outbound-connection=*"           ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=remoting/remote-outbound-connection=*"          ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=singleton/singleton-policy=*/election-policy=ran?"socket-binding-preferences" ?
?dom"                                                                  ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=singleton/singleton-policy=*/election-policy=sim?"socket-binding-preferences" ?
?ple"                                                                  ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=filter/mod-cluster=*"    ?"advertise-socket-binding"   ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=filter/mod-cluster=*"    ?"management-socket-binding"  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=filter/mod-cluster=*"    ?"worker"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=handler/reverse-proxy=*/h?"outbound-socket-binding"    ?
?ost=*"                                                                ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*"                                             ?"default-interface"          ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"socket-binding-ref"         ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/remote-destination-outbound-socket-binding=*"?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/socket-binding=*"                            ?"interface"                  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
{code}

This was a test against the model reported by an HC using host-master.xml and the standard domain.xml modified to add the rts, xts and picketlink extensions.

The Cypher query used was:

{code}
MATCH (r:Resource)-->(a:Attribute)-[:REFERENCES_CAPABILITY]->(c:Capability)
WHERE c IS NOT NULL AND 
      a.`expressions-allowed` = true
RETURN r.address, a.name
{code}

Following is a check of standalone using standalone-full-ha.xml.
{code}
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"r.address"                                                           ?"a.name"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*"                                             ?"default-interface"          ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"socket-binding-ref"         ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/remote-destination-outbound-socket-binding=*"?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/socket-binding=*"                            ?"interface"                  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=mail/mail-session=*/custom=*"                             ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=remoting/local-outbound-connection=*"                     ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=remoting/remote-outbound-connection=*"                    ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=singleton/singleton-policy=*/election-policy=random"      ?"socket-binding-preferences" ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=singleton/singleton-policy=*/election-policy=simple"      ?"socket-binding-preferences" ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=filter/mod-cluster=*"              ?"advertise-socket-binding"   ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=filter/mod-cluster=*"              ?"management-socket-binding"  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=filter/mod-cluster=*"              ?"worker"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=handler/reverse-proxy=*/host=*"    ?"outbound-socket-binding"    ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
{code}

[1] https://github.com/hal/model-graph  Sweet!
[2] https://neo4j.com/docs/cypher-refcard/current/

> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
>                 Key: WFCORE-887
>                 URL: https://issues.jboss.org/browse/WFCORE-887
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Alpha5
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We should look for other cases like this too, although those changes should be separate JIRAs. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 14:09:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Dec 2017 14:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.91492.1512587340320@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-887:
------------------------------------
    Description: 
SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.

Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.

There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.

We use INFO messages for other management API deprecation messages, but these I believe deserve a WARN. The issue here isn't just that we may change something in the future (seen as not justifying a WARN) but also that the capability/requirement bookkeeping for the attribute cannot be properly done if an expression is used, meaning the model integrity behavior meant to be in place cannot be used.

We should look for other cases like this too, although those changes should be separate JIRAs. 

  was:
SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.

Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.

There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.

We should look for other cases like this too, although those changes should be separate JIRAs. 



> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
>                 Key: WFCORE-887
>                 URL: https://issues.jboss.org/browse/WFCORE-887
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Alpha5
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We use INFO messages for other management API deprecation messages, but these I believe deserve a WARN. The issue here isn't just that we may change something in the future (seen as not justifying a WARN) but also that the capability/requirement bookkeeping for the attribute cannot be properly done if an expression is used, meaning the model integrity behavior meant to be in place cannot be used.
> We should look for other cases like this too, although those changes should be separate JIRAs. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 14:09:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 6 Dec 2017 14:09: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.1512587320000@Atlassian.JIRA>
References: <JIRA.12723833.1512587320000@Atlassian.JIRA>
	<JIRA.12723833.1512587320846@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723833.1512587320000.91495.1512587340452@Atlassian.JIRA>

James Perkins created LOGMGR-185:
------------------------------------

             Summary: 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


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  Wed Dec  6 14:10:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 6 Dec 2017 14:10: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.91497.1512587400289@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned LOGMGR-185:
------------------------------------

    Assignee: James Perkins


> 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
>
> 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  Wed Dec  6 14:10:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Dec 2017 14:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.91500.1512587400599@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502639#comment-13502639 ] 

Brian Stansberry edited comment on WFCORE-887 at 12/6/17 2:09 PM:
------------------------------------------------------------------

Analysis of the current (master) WildFly management API using the hal/model-graph[1] tool shows the following attributes that are credential references but also support expressions:

{code}
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"r.address"                                                           ?"a.name"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/core-service=management/management-interface=http-interf?"interface"                  ?
?ace"                                                                  ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/core-service=management/management-interface=native-inte?"interface"                  ?
?rface"                                                                ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*"                                 ?"default-interface"          ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/local-destination-outbound-socket?"socket-binding-ref"         ?
?-binding=*"                                                           ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/local-destination-outbound-socket?"source-interface"           ?
?-binding=*"                                                           ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/remote-destination-outbound-socke?"source-interface"           ?
?t-binding=*"                                                          ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/socket-binding=*"                ?"interface"                  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=mail/mail-session=*/custom=*"                   ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=remoting/local-outbound-connection=*"           ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=remoting/remote-outbound-connection=*"          ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=singleton/singleton-policy=*/election-policy=ran?"socket-binding-preferences" ?
?dom"                                                                  ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=singleton/singleton-policy=*/election-policy=sim?"socket-binding-preferences" ?
?ple"                                                                  ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=filter/mod-cluster=*"    ?"advertise-socket-binding"   ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=filter/mod-cluster=*"    ?"management-socket-binding"  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=filter/mod-cluster=*"    ?"worker"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=handler/reverse-proxy=*/h?"outbound-socket-binding"    ?
?ost=*"                                                                ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*"                                             ?"default-interface"          ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"socket-binding-ref"         ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/remote-destination-outbound-socket-binding=*"?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/socket-binding=*"                            ?"interface"                  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
{code}

This was a test against the model reported by an HC using host-master.xml and the standard domain.xml modified to add the rts, xts and picketlink extensions.

The Cypher query used was:

{code}
MATCH (r:Resource)-->(a:Attribute)-[:REFERENCES_CAPABILITY]->(c:Capability)
WHERE c IS NOT NULL AND 
      a.`expressions-allowed` = true
RETURN r.address, a.name
{code}

Following is a check of standalone using standalone-full-ha.xml.
{code}
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"r.address"                                                           ?"a.name"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*"                                             ?"default-interface"          ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"socket-binding-ref"         ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/remote-destination-outbound-socket-binding=*"?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/socket-binding=*"                            ?"interface"                  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=mail/mail-session=*/custom=*"                             ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=remoting/local-outbound-connection=*"                     ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=remoting/remote-outbound-connection=*"                    ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=singleton/singleton-policy=*/election-policy=random"      ?"socket-binding-preferences" ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=singleton/singleton-policy=*/election-policy=simple"      ?"socket-binding-preferences" ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=filter/mod-cluster=*"              ?"advertise-socket-binding"   ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=filter/mod-cluster=*"              ?"management-socket-binding"  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=filter/mod-cluster=*"              ?"worker"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=handler/reverse-proxy=*/host=*"    ?"outbound-socket-binding"    ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
{code}

[1] https://github.com/hal/model-graph  Sweet! Thank you [~harald.pehl]!
[2] https://neo4j.com/docs/cypher-refcard/current/


was (Author: brian.stansberry):
Analysis of the current (master) WildFly management API using the hal/model-graph[1] tool shows the following attributes that are credential references but also support expressions:

{code}
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"r.address"                                                           ?"a.name"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/core-service=management/management-interface=http-interf?"interface"                  ?
?ace"                                                                  ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/core-service=management/management-interface=native-inte?"interface"                  ?
?rface"                                                                ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*"                                 ?"default-interface"          ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/local-destination-outbound-socket?"socket-binding-ref"         ?
?-binding=*"                                                           ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/local-destination-outbound-socket?"source-interface"           ?
?-binding=*"                                                           ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/remote-destination-outbound-socke?"source-interface"           ?
?t-binding=*"                                                          ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/host=master/socket-binding-group=*/socket-binding=*"                ?"interface"                  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=mail/mail-session=*/custom=*"                   ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=remoting/local-outbound-connection=*"           ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=remoting/remote-outbound-connection=*"          ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=singleton/singleton-policy=*/election-policy=ran?"socket-binding-preferences" ?
?dom"                                                                  ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=singleton/singleton-policy=*/election-policy=sim?"socket-binding-preferences" ?
?ple"                                                                  ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=filter/mod-cluster=*"    ?"advertise-socket-binding"   ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=filter/mod-cluster=*"    ?"management-socket-binding"  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=filter/mod-cluster=*"    ?"worker"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/profile=*/subsystem=undertow/configuration=handler/reverse-proxy=*/h?"outbound-socket-binding"    ?
?ost=*"                                                                ?                             ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*"                                             ?"default-interface"          ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"socket-binding-ref"         ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/remote-destination-outbound-socket-binding=*"?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/socket-binding=*"                            ?"interface"                  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
{code}

This was a test against the model reported by an HC using host-master.xml and the standard domain.xml modified to add the rts, xts and picketlink extensions.

The Cypher query used was:

{code}
MATCH (r:Resource)-->(a:Attribute)-[:REFERENCES_CAPABILITY]->(c:Capability)
WHERE c IS NOT NULL AND 
      a.`expressions-allowed` = true
RETURN r.address, a.name
{code}

Following is a check of standalone using standalone-full-ha.xml.
{code}
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"r.address"                                                           ?"a.name"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*"                                             ?"default-interface"          ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"socket-binding-ref"         ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/local-destination-outbound-socket-binding=*" ?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/remote-destination-outbound-socket-binding=*"?"source-interface"           ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/socket-binding-group=*/socket-binding=*"                            ?"interface"                  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=mail/mail-session=*/custom=*"                             ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=remoting/local-outbound-connection=*"                     ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=remoting/remote-outbound-connection=*"                    ?"outbound-socket-binding-ref"?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=singleton/singleton-policy=*/election-policy=random"      ?"socket-binding-preferences" ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=singleton/singleton-policy=*/election-policy=simple"      ?"socket-binding-preferences" ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=filter/mod-cluster=*"              ?"advertise-socket-binding"   ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=filter/mod-cluster=*"              ?"management-socket-binding"  ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=filter/mod-cluster=*"              ?"worker"                     ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
?"/subsystem=undertow/configuration=handler/reverse-proxy=*/host=*"    ?"outbound-socket-binding"    ?
??????????????????????????????????????????????????????????????????????????????????????????????????????
{code}

[1] https://github.com/hal/model-graph  Sweet!
[2] https://neo4j.com/docs/cypher-refcard/current/

> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
>                 Key: WFCORE-887
>                 URL: https://issues.jboss.org/browse/WFCORE-887
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Alpha5
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We use INFO messages for other management API deprecation messages, but these I believe deserve a WARN. The issue here isn't just that we may change something in the future (seen as not justifying a WARN) but also that the capability/requirement bookkeeping for the attribute cannot be properly done if an expression is used, meaning the model integrity behavior meant to be in place cannot be used.
> We should look for other cases like this too, although those changes should be separate JIRAs. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 14:21:00 2017
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Wed, 6 Dec 2017 14:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9600) [GSS](7.2.0) Apostrophe in an
 attribute with multiple EL parts breaks function lookup
In-Reply-To: <JIRA.12723834.1512588042000@Atlassian.JIRA>
References: <JIRA.12723834.1512588042000@Atlassian.JIRA>
	<JIRA.12723834.1512588042541@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723834.1512588042000.91509.1512588060234@Atlassian.JIRA>

Brad Maxwell created WFLY-9600:
----------------------------------

             Summary: [GSS](7.2.0) Apostrophe in an attribute with multiple EL parts breaks function lookup
                 Key: WFLY-9600
                 URL: https://issues.jboss.org/browse/WFLY-9600
             Project: WildFly
          Issue Type: Bug
          Components: EE, Web (Undertow)
    Affects Versions: 10.0.0.Final
            Reporter: Brad Maxwell
            Assignee: Tomaz Cerar
            Priority: Critical
         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  Wed Dec  6 11:21:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4859) log INFO for
 messaging-activemq journal-type
In-Reply-To: <JIRA.12576867.1435827263000@Atlassian.JIRA>
References: <JIRA.12576867.1435827263000@Atlassian.JIRA>
	<JIRA.12576867.1435827263000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576867.1435827263000.88307.1512577263432@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-4859.
----------------------------


> log INFO for messaging-activemq journal-type
> --------------------------------------------
>
>                 Key: WFLY-4859
>                 URL: https://issues.jboss.org/browse/WFLY-4859
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.Alpha5
>
>
> In the messaging-activemq subsystem, the default journal type is AIO. 
> This type of journal only works on Linux (with LibAIO installed). On any other platforms, we log a WARN that AIO can not be installed and NIO will be used instead.
> We should have no WARN log when starting a pristine EAP servers.
> However, having AIO by default ensures that on Linux, we provide the best messaging performance out of the box.
> Instead of logging a WARN, we should only log an INFO telling the users that AIO can not be loaded and NIO will be used.
> There is no functionality problem using NIO instead of AIO, only best performance will not be achieved.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 11:21:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 11:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-416) Complete <xs:documentation>
 for all configuration elements/attributes in Infinispan subsystem's XSD
In-Reply-To: <JIRA.12461886.1331909436000@Atlassian.JIRA>
References: <JIRA.12461886.1331909436000@Atlassian.JIRA>
	<JIRA.12461886.1331909436000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461886.1331909436000.88313.1512577263644@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-416.
---------------------------


> Complete <xs:documentation> for all configuration elements/attributes in Infinispan subsystem's XSD
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-416
>                 URL: https://issues.jboss.org/browse/WFLY-416
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final, 8.1.0.Final
>            Reporter: Martin Gencur
>            Assignee: Radoslav Husar
>              Labels: ux
>             Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> Infinispan subsystem's XSD still contains a lot of elements/attributes which do NOT have their description: https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-as-infinispan_1_1.xsd
> It would be very useful for users to know what each element is supposed to do.
> This document can help out: https://docspace.corp.redhat.com/docs/DOC-69249



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:27:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:27:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7289) Adding ldap-key-store
 requires accessible ldap server
In-Reply-To: <JIRA.12654219.1476189896000@Atlassian.JIRA>
References: <JIRA.12654219.1476189896000@Atlassian.JIRA>
	<JIRA.12654219.1476189896000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654219.1476189896000.90589.1512581225269@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7289:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Adding ldap-key-store requires accessible ldap server
> -----------------------------------------------------
>
>                 Key: WFLY-7289
>                 URL: https://issues.jboss.org/browse/WFLY-7289
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Final
>
>
> Playing with ldap-key-store . What I consider very unconvenient is fact, that in moment of adding ldap-key-store, ldap server has to be running and accessible. Elytron ldap-realm does not need that. Doubt about legacy security realms. Is it possible to decouple that dependency and leave that check till first ldap-key-store usage?
> Steps to reproduce:
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/dir-context=a:add()
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=a:add(dir-context=a, search-path="a")
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> {code}
> leads to exception in server log
> {code}
> 14:37:25,917 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
>     "address" => [
>         ("subsystem" => "elytron"),
>         ("ldap-key-store" => "a")
>     ],
>     "operation" => "add",
>     "search-path" => "a",
>     "dir-context" => "a",
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE"
>     }
> }]: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> 	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildTypes(AbstractModelResource.java:372)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:787)
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:520)
> 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:758)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:709)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	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:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> Caused by: javax.naming.NamingException: Cannot parse url: undefined [Root exception is java.net.MalformedURLException: Invalid URI: undefined]
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:92)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:163)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 39 more
> Caused by: java.net.MalformedURLException: Invalid URI: undefined
> 	at com.sun.jndi.toolkit.url.Uri.parse(Uri.java:199)
> 	at com.sun.jndi.toolkit.url.Uri.init(Uri.java:138)
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:82)
> 	... 56 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:30:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour
 for EJBs if JTS is enabled
In-Reply-To: <JIRA.12550797.1409580819000@Atlassian.JIRA>
References: <JIRA.12550797.1409580819000@Atlassian.JIRA>
	<JIRA.12550797.1409580819000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12550797.1409580819000.91089.1512581400911@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-3801:
-----------------------------
    Fix Version/s: 11.0.0.Final


> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
>                 Key: WFLY-3801
>                 URL: https://issues.jboss.org/browse/WFLY-3801
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.1.0.Final
>         Environment: standalone-full profile with JTS enabled
>            Reporter: Wolf-Dieter Fink
>            Assignee: Stuart Douglas
>             Fix For: 11.0.0.Final
>
>         Attachments: 456a624-withDestroy.log, 8d49872-error.log, enableJTS.cli, reproducer.zip, server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
>    WARN  [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance  Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:31:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:31:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour
 for EJBs if JTS is enabled
In-Reply-To: <JIRA.12550797.1409580819000@Atlassian.JIRA>
References: <JIRA.12550797.1409580819000@Atlassian.JIRA>
	<JIRA.12550797.1409580819000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12550797.1409580819000.91108.1512581461476@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502605#comment-13502605 ] 

Kabir Khan commented on WFLY-3801:
----------------------------------

I am bulk closing old issues that were resolved with no fix version. From the history of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
>                 Key: WFLY-3801
>                 URL: https://issues.jboss.org/browse/WFLY-3801
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.1.0.Final
>         Environment: standalone-full profile with JTS enabled
>            Reporter: Wolf-Dieter Fink
>            Assignee: Stuart Douglas
>             Fix For: 11.0.0.Final
>
>         Attachments: 456a624-withDestroy.log, 8d49872-error.log, enableJTS.cli, reproducer.zip, server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
>    WARN  [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance  Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:31:02 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:31:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour
 for EJBs if JTS is enabled
In-Reply-To: <JIRA.12550797.1409580819000@Atlassian.JIRA>
References: <JIRA.12550797.1409580819000@Atlassian.JIRA>
	<JIRA.12550797.1409580819000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12550797.1409580819000.91125.1512581462097@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-3801.
----------------------------


> Wrong Transaction behaviour for EJBs if JTS is enabled
> ------------------------------------------------------
>
>                 Key: WFLY-3801
>                 URL: https://issues.jboss.org/browse/WFLY-3801
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.1.0.Final
>         Environment: standalone-full profile with JTS enabled
>            Reporter: Wolf-Dieter Fink
>            Assignee: Stuart Douglas
>             Fix For: 11.0.0.Final
>
>         Attachments: 456a624-withDestroy.log, 8d49872-error.log, enableJTS.cli, reproducer.zip, server.log
>
>
> If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation:
>    WARN  [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive
> This is only the case if other resources are involved, i.e. a DB via JPA.
> If a simple bean is used (like ejb-remote quickstart) this warning is not shown.
> It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance  Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec  6 12:33:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 6 Dec 2017 12:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7209) Operation to list installed
 Resource Adapters
In-Reply-To: <JIRA.12651854.1474714280000@Atlassian.JIRA>
References: <JIRA.12651854.1474714280000@Atlassian.JIRA>
	<JIRA.12651854.1474714280000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651854.1474714280000.91133.1512581580293@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7209:
-----------------------------

Resetting the fix version as it is still open and 10.1.0 was a long time ago. If it should be resolved, please do so (and close) against the relevant fix version

> Operation to list installed Resource Adapters
> ---------------------------------------------
>
>                 Key: WFLY-7209
>                 URL: https://issues.jboss.org/browse/WFLY-7209
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Guillermo Gonz?lez de Ag?ero
>            Assignee: Stefano Maestri
>             Fix For: 10.1.0.Final
>
>         Attachments: 1-jdbc.png, 2-ra.png
>
>
> Currently there's no way to list all the deployed Resource Adapters (modules or deployed archives). I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers (see attached screenshots). This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec  6 17:01:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 6 Dec 2017 17:01: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.92042.1512597660091@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502673#comment-13502673 ] 

Jan Kalina commented on ELY-283:
--------------------------------

Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...

{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/69206038
c/r/s = 0/13/0 
{code}
{code}
major = d0000 = 0 / 13 / 0
    Calling Error = 0
    Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
    Supplementary Status Bits = 0
minor = 69206038 (dec)
{code}


> 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
>
>
> 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 Dec  6 17:33:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 6 Dec 2017 17: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.92107.1512599580131@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502673#comment-13502673 ] 

Jan Kalina edited comment on ELY-283 at 12/6/17 5:32 PM:
---------------------------------------------------------

Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...

{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/69206038
c/r/s = 0/13/0 
{code}
{code}
major = d0000 = 0 / 13 / 0
    Calling Error = 0
    Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
    Supplementary Status Bits = 0
minor = 69206038 (dec) =  04200016 (hex)
{code}


was (Author: honza889):
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...

{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/69206038
c/r/s = 0/13/0 
{code}
{code}
major = d0000 = 0 / 13 / 0
    Calling Error = 0
    Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
    Supplementary Status Bits = 0
minor = 69206038 (dec)
{code}


> 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
>
>
> 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 Dec  7 02:27:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 7 Dec 2017 02:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6174) Upgrade Weld to 2.3.3.Final
In-Reply-To: <JIRA.12603497.1455183541000@Atlassian.JIRA>
References: <JIRA.12603497.1455183541000@Atlassian.JIRA>
	<JIRA.12603497.1455183541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603497.1455183541000.92881.1512631620511@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reopened WFLY-6174:
--------------------------------


> Upgrade Weld to 2.3.3.Final
> ---------------------------
>
>                 Key: WFLY-6174
>                 URL: https://issues.jboss.org/browse/WFLY-6174
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: CDI / Weld
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 10.1.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 02:27:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 7 Dec 2017 02:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6174) Upgrade Weld to 2.3.3.Final
In-Reply-To: <JIRA.12603497.1455183541000@Atlassian.JIRA>
References: <JIRA.12603497.1455183541000@Atlassian.JIRA>
	<JIRA.12603497.1455183541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603497.1455183541000.92886.1512631620633@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated WFLY-6174:
-------------------------------
    Fix Version/s: 10.1.0.Final
                       (was: 11.0.0.Final)


> Upgrade Weld to 2.3.3.Final
> ---------------------------
>
>                 Key: WFLY-6174
>                 URL: https://issues.jboss.org/browse/WFLY-6174
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: CDI / Weld
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 10.1.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 02:27:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 7 Dec 2017 02:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6174) Upgrade Weld to 2.3.3.Final
In-Reply-To: <JIRA.12603497.1455183541000@Atlassian.JIRA>
References: <JIRA.12603497.1455183541000@Atlassian.JIRA>
	<JIRA.12603497.1455183541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603497.1455183541000.92891.1512631620770@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba closed WFLY-6174.
------------------------------
    Resolution: Done


> Upgrade Weld to 2.3.3.Final
> ---------------------------
>
>                 Key: WFLY-6174
>                 URL: https://issues.jboss.org/browse/WFLY-6174
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: CDI / Weld
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 10.1.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 02:28:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 7 Dec 2017 02:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6796) Upgrade Weld to 2.3.5.Final
In-Reply-To: <JIRA.12636541.1467360888000@Atlassian.JIRA>
References: <JIRA.12636541.1467360888000@Atlassian.JIRA>
	<JIRA.12636541.1467360888000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12636541.1467360888000.92895.1512631680452@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reopened WFLY-6796:
--------------------------------


> Upgrade Weld to 2.3.5.Final
> ---------------------------
>
>                 Key: WFLY-6796
>                 URL: https://issues.jboss.org/browse/WFLY-6796
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: CDI / Weld
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 10.1.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 02:28:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 7 Dec 2017 02:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6796) Upgrade Weld to 2.3.5.Final
In-Reply-To: <JIRA.12636541.1467360888000@Atlassian.JIRA>
References: <JIRA.12636541.1467360888000@Atlassian.JIRA>
	<JIRA.12636541.1467360888000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12636541.1467360888000.92902.1512631680607@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated WFLY-6796:
-------------------------------
    Fix Version/s: 10.1.0.Final
                       (was: 11.0.0.Final)


> Upgrade Weld to 2.3.5.Final
> ---------------------------
>
>                 Key: WFLY-6796
>                 URL: https://issues.jboss.org/browse/WFLY-6796
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: CDI / Weld
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 10.1.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 02:28:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 7 Dec 2017 02:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6796) Upgrade Weld to 2.3.5.Final
In-Reply-To: <JIRA.12636541.1467360888000@Atlassian.JIRA>
References: <JIRA.12636541.1467360888000@Atlassian.JIRA>
	<JIRA.12636541.1467360888000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12636541.1467360888000.92906.1512631680781@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba closed WFLY-6796.
------------------------------
    Resolution: Done


> Upgrade Weld to 2.3.5.Final
> ---------------------------
>
>                 Key: WFLY-6796
>                 URL: https://issues.jboss.org/browse/WFLY-6796
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: CDI / Weld
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 10.1.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 03:02:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 7 Dec 2017 03:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3442) CLI can't reload if
 authentication configuration changed
In-Reply-To: <JIRA.12723325.1512398892000@Atlassian.JIRA>
References: <JIRA.12723325.1512398892000@Atlassian.JIRA>
	<JIRA.12723325.1512398892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723325.1512398892000.92961.1512633720177@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise updated WFCORE-3442:
-----------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2971


> CLI can't reload if authentication configuration changed
> --------------------------------------------------------
>
>                 Key: WFCORE-3442
>                 URL: https://issues.jboss.org/browse/WFCORE-3442
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> The context:
> - Legacy ManagementRealm, no local-auth enabled, only users located properties file.
> - SASL authentication factory, digest with FooRealm, userName/password in other properties file
> The http management interface
> - Reference ManagementRealm and upgrade references SAL factory.
> From CLI:
> 1) User connects using credentials required for FooRealm
> 2) User disables SASL authentication : /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory,value=undefined
> 3) User reloads ==> Connection fails.
> The user should be prompted for ManagementRealm credentials (if the current ones are not valid in the context of this realm).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 03:30:00 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Thu, 7 Dec 2017 03:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.93073.1512635400963@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502774#comment-13502774 ] 

Alberto Gori commented on ELY-1455:
-----------------------------------

Thanks for explanation. I am not sure I understood it completely. 

Is it incorrect to declare a FORM authentication and use programmatic API instead? If so, what am I supposed to declare in auth-method tag in web.xml if I want to stick to programmatic API?

Or you were saying that this configuration is hitting a bug in elytron/wildfly?

Anyway, I think I'll go for option 2 (if FORM + API is ok).

Also, are these bugs related to SSO (that is not working at all)?


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         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 Dec  7 03:30:01 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Thu, 7 Dec 2017 03:30:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.93078.1512635401118@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502774#comment-13502774 ] 

Alberto Gori edited comment on ELY-1455 at 12/7/17 3:29 AM:
------------------------------------------------------------

Thanks for explanation. I am not sure I understood it completely, though. 

Is it incorrect to declare a FORM authentication and use programmatic API instead? If so, what am I supposed to declare in auth-method tag in web.xml if I want to stick to programmatic API?

Or you were saying that this configuration is hitting a bug in elytron/wildfly?

Anyway, I think I'll go for option 2 (if FORM + API is ok).

Also, are these bugs related to SSO (that is not working at all)?



was (Author: lagoria):
Thanks for explanation. I am not sure I understood it completely. 

Is it incorrect to declare a FORM authentication and use programmatic API instead? If so, what am I supposed to declare in auth-method tag in web.xml if I want to stick to programmatic API?

Or you were saying that this configuration is hitting a bug in elytron/wildfly?

Anyway, I think I'll go for option 2 (if FORM + API is ok).

Also, are these bugs related to SSO (that is not working at all)?


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         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 Dec  7 03:33:01 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 7 Dec 2017 03:33:01 -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.93139.1512635581258@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502781#comment-13502781 ] 

Jean-Francois Denise commented on WFCORE-3450:
----------------------------------------------

[~iweiss], you made a point related to documentation, we need to document that '*' means required. I will add a note in the cli help. This should have been done first place.
Coloured CLI would be something to discuss. As soon as we choose some colours, we would have people liking them and other not liking. Making colours configurable seems a bit too much to me. Colours are also not interpreted the same way on various platforms, so colouring should be adapted per platform. Personally I don't think that coloured terminal is helpful, I much prefer back and white. bold could be a good alternative for required attributes.

BTW, Aesh already supports that by the mean of ANSI. I remember that [~ehugonnet] did some prototyping to colour operation failure in red.





> 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
>
> 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  Thu Dec  7 03:59:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 7 Dec 2017 03:59:00 -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.93222.1512637140230@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502791#comment-13502791 ] 

Jean-Francois Denise commented on WFCORE-3450:
----------------------------------------------

I have added the following note in help: https://github.com/wildfly/wildfly-core/pull/2976

> 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
>
> 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  Thu Dec  7 04:32:00 2017
From: issues at jboss.org (andrea tarocchi (JIRA))
Date: Thu, 7 Dec 2017 04:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2240) Log a warning if no binding
 port in TCP is provided
In-Reply-To: <JIRA.12723889.1512639116000@Atlassian.JIRA>
References: <JIRA.12723889.1512639116000@Atlassian.JIRA>
	<JIRA.12723889.1512639116845@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723889.1512639116000.93333.1512639120173@Atlassian.JIRA>

andrea tarocchi created JGRP-2240:
-------------------------------------

             Summary: Log a warning if no binding port in TCP is provided
                 Key: JGRP-2240
                 URL: https://issues.jboss.org/browse/JGRP-2240
             Project: JGroups
          Issue Type: Enhancement
    Affects Versions: 4.0.9
            Reporter: andrea tarocchi
            Assignee: Bela Ban
            Priority: Minor


If a bind port is not defined and you don't bind (for some reason) to the default one, log a warning.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 04:47:02 2017
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Thu, 7 Dec 2017 04:47:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6880) Disable slow client
 reconnecting with KILL slow client policy
In-Reply-To: <JIRA.12640587.1469495241000@Atlassian.JIRA>
References: <JIRA.12640587.1469495241000@Atlassian.JIRA>
	<JIRA.12640587.1469495241000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640587.1469495241000.93454.1512640022369@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502816#comment-13502816 ] 

Miroslav Novak commented on WFLY-6880:
--------------------------------------

Hi [~bayern39], it seems that this feature was implemented in Artemis 1.4. WF11 contain Artemis 1.5.5 and this should be solved there. Can this feature request be resolved?

> Disable slow client reconnecting with KILL slow client policy 
> --------------------------------------------------------------
>
>                 Key: WFLY-6880
>                 URL: https://issues.jboss.org/browse/WFLY-6880
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 10.0.0.Final
>            Reporter: Chen Maoqian
>            Assignee: Chen Maoqian
>            Priority: Minor
>
> It is possible to detect and handle(KILL, NOTIFY) slow consumers. In case policy KILL is used and connection factory used to create connection of slow consumer has attribute {{reconnect-attempts}} set to {{"-1"}}, slow consumer reconnects to server. This consumer is then reconnects, is detected as slow and disconnected. 
> Attribute {{reconnect-attempts="-1"}} should be ignored, and slow client should not be trying to reconnect once it is disconnected by KILL slow consumer policy.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 04:56:00 2017
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Thu, 7 Dec 2017 04:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.93475.1512640560145@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502818#comment-13502818 ] 

Harald Pehl commented on WFCORE-887:
------------------------------------

Cool. Glad to see that the tool is useful after all ;-)

> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
>                 Key: WFCORE-887
>                 URL: https://issues.jboss.org/browse/WFCORE-887
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Alpha5
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We use INFO messages for other management API deprecation messages, but these I believe deserve a WARN. The issue here isn't just that we may change something in the future (seen as not justifying a WARN) but also that the capability/requirement bookkeeping for the attribute cannot be properly done if an expression is used, meaning the model integrity behavior meant to be in place cannot be used.
> We should look for other cases like this too, although those changes should be separate JIRAs. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 04:59:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 7 Dec 2017 04:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.93503.1512640740501@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502821#comment-13502821 ] 

Martin Choma commented on ELY-1455:
-----------------------------------

You should use j_security_check in conjuction with FORM per se.

{quote}
In order for the authentication to proceed appropriately, the action of the login form must always be j_security_check.
{quote}

You can use BASIC. Or if you want FORM authentication you are probably left to fully application handling.

[1] http://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/servlet-3_0-final-spec.pdf?AuthParam=1512639995_da4a1bf0776219ef08f5affee7ec08f2

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         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 Dec  7 05:00:00 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 7 Dec 2017 05:00: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.93508.1512640800243@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502823#comment-13502823 ] 

Michael Biarnes Kiefer commented on DROOLS-2165:
------------------------------------------------

[~ge0ffrey] i suppose on master and on 7.5.x ?

> 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  Thu Dec  7 05:00:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 7 Dec 2017 05:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.93512.1512640800376@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502821#comment-13502821 ] 

Martin Choma edited comment on ELY-1455 at 12/7/17 4:59 AM:
------------------------------------------------------------

You should use j_security_check in conjuction with FORM per se.

{quote}
In order for the authentication to proceed appropriately, the action of the login form must always be j_security_check.
{quote}

You can use BASIC. Or if you want login form authentication you are probably left to fully application handling in that case.

[1] http://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/servlet-3_0-final-spec.pdf?AuthParam=1512639995_da4a1bf0776219ef08f5affee7ec08f2


was (Author: mchoma):
You should use j_security_check in conjuction with FORM per se.

{quote}
In order for the authentication to proceed appropriately, the action of the login form must always be j_security_check.
{quote}

You can use BASIC. Or if you want FORM authentication you are probably left to fully application handling.

[1] http://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/servlet-3_0-final-spec.pdf?AuthParam=1512639995_da4a1bf0776219ef08f5affee7ec08f2

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         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 Dec  7 05:24:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 05:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.93634.1512642240670@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502839#comment-13502839 ] 

Darran Lofthouse commented on ELY-1455:
---------------------------------------

+1 If you update the login page so it's submission is compatible with the Servlet specification defined FORM authentication mechanism then this mechanism will take over the authentication including the storage of the resulting SecurityIdentity for use on subsequent requests, here is an example of a simple FORM: -

{code}
<html>
  <head>
    <title>Login Page</title>
  </head>
<body>
  <font size='5' color='blue'>Please Login</font><hr>

  <form action='j_security_check' method='post'>
    <table>
     <tr><td>Name:</td>
       <td><input type='text' name='j_username'></td></tr>
     <tr><td>Password:</td> 
       <td><input type='password' name='j_password' size='8'></td>
     </tr>
    </table>
  <br>
    <input type='submit' value='login'> 
  </form>
</body>
</html>
{code}

Note:  The action AND the two input fields are required to use 'j_security_check', 'j_username', 'j_password' need to use respectively.

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         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 Dec  7 05:29:00 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Thu, 7 Dec 2017 05:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.93665.1512642540182@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502846#comment-13502846 ] 

Alberto Gori commented on ELY-1455:
-----------------------------------

Thanks Martin. I am confused now :) 

There is a lot of (even expert like BalusC) people in stackoverflow suggesting this combo (programmatic + form).

Anyway as for BASIC, I don't think anyone is using it in 2017. So if you need a secure and customizable authentication, you need  programmatic login.

Fully application handling means even no request.login method? So I have to write a filter to check session and my own JDBC (or JPA) query (this is actually what I was used to do before trying standard authentication)? 

And if so, what about SSO that seems to be coupled to standard authentication mechanisms in Wildfly?

Just trying to understand what is the best practice in JEE for a simple login form.

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         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 Dec  7 05:52:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 7 Dec 2017 05:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.93823.1512643920624@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502866#comment-13502866 ] 

Martin Choma commented on ELY-1455:
-----------------------------------

I meant to have no auth method configured in web.xml. And render application login module if not authenticated. 

Can you reference solutions using (programmatic + form ) advice?

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         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 Dec  7 06:06:00 2017
From: issues at jboss.org (Alberto Gori (JIRA))
Date: Thu, 7 Dec 2017 06:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.93910.1512644760335@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502879#comment-13502879 ] 

Alberto Gori commented on ELY-1455:
-----------------------------------

Sure:

https://stackoverflow.com/questions/14687572/programmatic-form-based-authentication (BalusC)

https://stackoverflow.com/questions/13714177/jsf-java-ee-form-vs-programmatic-authentication (BalusC)

https://stackoverflow.com/questions/21500311/how-to-use-j-security-check-jsf (check answer by Mariotti at the bottom)

No auth method is ok, but would SSO work somehow? 

>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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
>             Fix For: 1.2.0.Beta11
>
>         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 Dec  7 06:10:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Thu, 7 Dec 2017 06:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-183) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723786.1512572196000@Atlassian.JIRA>
References: <JIRA.12723786.1512572196000@Atlassian.JIRA>
	<JIRA.12723786.1512572196000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723786.1512572196000.93942.1512645000895@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman reassigned JBEE-183:
---------------------------------

    Assignee: Tomas Hofman


> NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBEE-183
>                 URL: https://issues.jboss.org/browse/JBEE-183
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>         Environment: - JBoss EAP 7.0.8
> - jboss-jstl-api_1.2_spec-1.1.3.Final
>            Reporter: Masafumi Miura
>            Assignee: Tomas Hofman
>         Attachments: byteman-script.btm, example.zip
>
>
> The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 
> Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)
> {code}
> ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
>     ...(snip)...
>     ...
> Caused by: java.lang.NullPointerException
>     at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
>     at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
>     at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
>     at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
>     at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
>     at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
>     at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     ... 61 more
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277
> {code}
> 252     public Object parseExpressionString(String pExpressionString)
> 253             throws ELException {
> 254         // See if it's an empty String
> 255         if (pExpressionString.length() == 0) {
> 256             return "";
> 257         }
> 258
> 259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
> 260             createExpressionStringMap();
> 261         }
> 262
> 263         // See if it's in the cache
> 264         Object ret =
> 265                 mBypassCache ?
> 266                         null :
> 267                         sCachedExpressionStrings.get(pExpressionString);
> 268
> 269         if (ret == null) {
> 270             // Parse the expression
> 271             Reader r = new StringReader(pExpressionString);
> 272             ELParser parser = new ELParser(r);
> 273             try {
> 274                 ret = parser.ExpressionString();
> 275                 if (!mBypassCache) {
> 276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
> 277                 }
> 278             }
> 279             catch (ParseException exc) {
> 280                 throw new ELException
> 281                         (formatParseException(pExpressionString,
> 282                                 exc));
> 283             }
> 284             catch (TokenMgrError exc) {
> 285                 // Note - this should never be reached, since the parser is
> 286                 // constructed to tokenize any input (illegal inputs get
> 287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
> 288                 // <ILLEGAL_CHARACTER>
> 289                 throw new ELException(exc.getMessage());
> 290             }
> 291         }
> 292         return ret;
> 293     }
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71
> {code}
> ~~~
>  51     /**
>  52      * The singleton instance of the evaluator *
>  53      */
>  54     static ELEvaluator sEvaluator =
>  55             new ELEvaluator
>  56                     (new JSTLVariableResolver());
>  :
>  62     /**
>  63      * Translation time validation of an attribute value.  This method
>  64      * will return a null String if the attribute value is valid;
>  65      * otherwise an error message.
>  66      */
>  67     public String validate(String pAttributeName,
>  68                            String pAttributeValue) {
>  69         try {
>  70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
>  71             sEvaluator.parseExpressionString(pAttributeValue);
>  72             sEvaluator.setBypassCache(false);
>  73             return null;
>  74         }
>  75         catch (ELException exc) {
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 06:14:00 2017
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Thu, 7 Dec 2017 06:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-183) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723786.1512572196000@Atlassian.JIRA>
References: <JIRA.12723786.1512572196000@Atlassian.JIRA>
	<JIRA.12723786.1512572196000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723786.1512572196000.93953.1512645240516@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitrii Tikhomirov reassigned JBEE-183:
---------------------------------------

    Assignee: Dmitrii Tikhomirov  (was: Tomas Hofman)


> NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBEE-183
>                 URL: https://issues.jboss.org/browse/JBEE-183
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>         Environment: - JBoss EAP 7.0.8
> - jboss-jstl-api_1.2_spec-1.1.3.Final
>            Reporter: Masafumi Miura
>            Assignee: Dmitrii Tikhomirov
>         Attachments: byteman-script.btm, example.zip
>
>
> The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 
> Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)
> {code}
> ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
>     ...(snip)...
>     ...
> Caused by: java.lang.NullPointerException
>     at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
>     at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
>     at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
>     at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
>     at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
>     at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
>     at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     ... 61 more
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277
> {code}
> 252     public Object parseExpressionString(String pExpressionString)
> 253             throws ELException {
> 254         // See if it's an empty String
> 255         if (pExpressionString.length() == 0) {
> 256             return "";
> 257         }
> 258
> 259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
> 260             createExpressionStringMap();
> 261         }
> 262
> 263         // See if it's in the cache
> 264         Object ret =
> 265                 mBypassCache ?
> 266                         null :
> 267                         sCachedExpressionStrings.get(pExpressionString);
> 268
> 269         if (ret == null) {
> 270             // Parse the expression
> 271             Reader r = new StringReader(pExpressionString);
> 272             ELParser parser = new ELParser(r);
> 273             try {
> 274                 ret = parser.ExpressionString();
> 275                 if (!mBypassCache) {
> 276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
> 277                 }
> 278             }
> 279             catch (ParseException exc) {
> 280                 throw new ELException
> 281                         (formatParseException(pExpressionString,
> 282                                 exc));
> 283             }
> 284             catch (TokenMgrError exc) {
> 285                 // Note - this should never be reached, since the parser is
> 286                 // constructed to tokenize any input (illegal inputs get
> 287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
> 288                 // <ILLEGAL_CHARACTER>
> 289                 throw new ELException(exc.getMessage());
> 290             }
> 291         }
> 292         return ret;
> 293     }
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71
> {code}
> ~~~
>  51     /**
>  52      * The singleton instance of the evaluator *
>  53      */
>  54     static ELEvaluator sEvaluator =
>  55             new ELEvaluator
>  56                     (new JSTLVariableResolver());
>  :
>  62     /**
>  63      * Translation time validation of an attribute value.  This method
>  64      * will return a null String if the attribute value is valid;
>  65      * otherwise an error message.
>  66      */
>  67     public String validate(String pAttributeName,
>  68                            String pAttributeValue) {
>  69         try {
>  70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
>  71             sEvaluator.parseExpressionString(pAttributeValue);
>  72             sEvaluator.setBypassCache(false);
>  73             return null;
>  74         }
>  75         catch (ELException exc) {
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 06:26:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Thu, 7 Dec 2017 06:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-183) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723786.1512572196000@Atlassian.JIRA>
References: <JIRA.12723786.1512572196000@Atlassian.JIRA>
	<JIRA.12723786.1512572196000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723786.1512572196000.94019.1512645960575@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman reassigned JBEE-183:
---------------------------------

    Assignee: Tomas Hofman  (was: Dmitrii Tikhomirov)


> NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBEE-183
>                 URL: https://issues.jboss.org/browse/JBEE-183
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>         Environment: - JBoss EAP 7.0.8
> - jboss-jstl-api_1.2_spec-1.1.3.Final
>            Reporter: Masafumi Miura
>            Assignee: Tomas Hofman
>         Attachments: byteman-script.btm, example.zip
>
>
> The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 
> Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)
> {code}
> ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
>     ...(snip)...
>     ...
> Caused by: java.lang.NullPointerException
>     at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
>     at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
>     at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
>     at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
>     at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
>     at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
>     at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     ... 61 more
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277
> {code}
> 252     public Object parseExpressionString(String pExpressionString)
> 253             throws ELException {
> 254         // See if it's an empty String
> 255         if (pExpressionString.length() == 0) {
> 256             return "";
> 257         }
> 258
> 259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
> 260             createExpressionStringMap();
> 261         }
> 262
> 263         // See if it's in the cache
> 264         Object ret =
> 265                 mBypassCache ?
> 266                         null :
> 267                         sCachedExpressionStrings.get(pExpressionString);
> 268
> 269         if (ret == null) {
> 270             // Parse the expression
> 271             Reader r = new StringReader(pExpressionString);
> 272             ELParser parser = new ELParser(r);
> 273             try {
> 274                 ret = parser.ExpressionString();
> 275                 if (!mBypassCache) {
> 276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
> 277                 }
> 278             }
> 279             catch (ParseException exc) {
> 280                 throw new ELException
> 281                         (formatParseException(pExpressionString,
> 282                                 exc));
> 283             }
> 284             catch (TokenMgrError exc) {
> 285                 // Note - this should never be reached, since the parser is
> 286                 // constructed to tokenize any input (illegal inputs get
> 287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
> 288                 // <ILLEGAL_CHARACTER>
> 289                 throw new ELException(exc.getMessage());
> 290             }
> 291         }
> 292         return ret;
> 293     }
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71
> {code}
> ~~~
>  51     /**
>  52      * The singleton instance of the evaluator *
>  53      */
>  54     static ELEvaluator sEvaluator =
>  55             new ELEvaluator
>  56                     (new JSTLVariableResolver());
>  :
>  62     /**
>  63      * Translation time validation of an attribute value.  This method
>  64      * will return a null String if the attribute value is valid;
>  65      * otherwise an error message.
>  66      */
>  67     public String validate(String pAttributeName,
>  68                            String pAttributeValue) {
>  69         try {
>  70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
>  71             sEvaluator.parseExpressionString(pAttributeValue);
>  72             sEvaluator.setBypassCache(false);
>  73             return null;
>  74         }
>  75         catch (ELException exc) {
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:25:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Thu, 7 Dec 2017 07:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-212) Automation Testcase
In-Reply-To: <JIRA.12723743.1512562833000@Atlassian.JIRA>
References: <JIRA.12723743.1512562833000@Atlassian.JIRA>
	<JIRA.12723743.1512562833000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723743.1512562833000.94326.1512649500379@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502921#comment-13502921 ] 

Hayk Hovsepyan commented on HAWKULARQE-212:
-------------------------------------------

PR sent https://github.com/ManageIQ/integration_tests/pull/6097

> Automation Testcase
> -------------------
>
>                 Key: HAWKULARQE-212
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-212
>             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 Dec  7 07:34:00 2017
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Thu, 7 Dec 2017 07:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2168) Extend concurrency test
	coverage
In-Reply-To: <JIRA.12723924.1512650027000@Atlassian.JIRA>
References: <JIRA.12723924.1512650027000@Atlassian.JIRA>
	<JIRA.12723924.1512650027381@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723924.1512650027000.94356.1512650040423@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2168:
-------------------------------------

             Summary: Extend concurrency test coverage
                 Key: DROOLS-2168
                 URL: https://issues.jboss.org/browse/DROOLS-2168
             Project: Drools
          Issue Type: Task
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Tibor Zim?nyi
             Fix For: 7.6.0.Final


Coverage for concurrency scenarios must be extended (E.g. coverage using subnetworks, sharing sessions, etc. ).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Dec  7 07:44:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1456) Two same SQL queries seen
 during one authentication attempt
In-Reply-To: <JIRA.12722891.1512035276000@Atlassian.JIRA>
References: <JIRA.12722891.1512035276000@Atlassian.JIRA>
	<JIRA.12722891.1512035276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722891.1512035276000.94391.1512650640600@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-1456:
-------------------------------------

    Assignee: Darran Lofthouse


> Two same SQL queries seen during one authentication attempt 
> ------------------------------------------------------------
>
>                 Key: ELY-1456
>                 URL: https://issues.jboss.org/browse/ELY-1456
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta11
>
>
> Two same sql queries are performed on authentication attempt using jdbc-realm.
> {noformat}
> 2017-11-29T15:53:32.399596Z   338 Query select password from user where email = 'alberto at myapp.com'
> 2017-11-29T15:53:32.400879Z   338 Query select role, 'Roles' from user_role_auth where email = 'alberto at myapp.com'
> 2017-11-29T15:53:32.402531Z   338 Query select password from user where email = 'alberto at myapp.com'
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:44:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1456) Two same SQL queries seen
 during one authentication attempt
In-Reply-To: <JIRA.12722891.1512035276000@Atlassian.JIRA>
References: <JIRA.12722891.1512035276000@Atlassian.JIRA>
	<JIRA.12722891.1512035276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722891.1512035276000.94395.1512650640687@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1456:
----------------------------------
    Priority: Critical  (was: Major)


> Two same SQL queries seen during one authentication attempt 
> ------------------------------------------------------------
>
>                 Key: ELY-1456
>                 URL: https://issues.jboss.org/browse/ELY-1456
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta11
>
>
> Two same sql queries are performed on authentication attempt using jdbc-realm.
> {noformat}
> 2017-11-29T15:53:32.399596Z   338 Query select password from user where email = 'alberto at myapp.com'
> 2017-11-29T15:53:32.400879Z   338 Query select role, 'Roles' from user_role_auth where email = 'alberto at myapp.com'
> 2017-11-29T15:53:32.402531Z   338 Query select password from user where email = 'alberto at myapp.com'
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:44:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using FORM mechanism.
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.94400.1512650640789@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1455:
----------------------------------
    Priority: Critical  (was: Major)


>  DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
>                 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.Beta11
>
>         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 Dec  7 07:45:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1448) API Compatibility for
 org.wildfly.security.mechanism.MechanismUtil
In-Reply-To: <JIRA.12721453.1510941462000@Atlassian.JIRA>
References: <JIRA.12721453.1510941462000@Atlassian.JIRA>
	<JIRA.12721453.1510941462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721453.1510941462000.94404.1512650700370@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1448:
----------------------------------
    Priority: Major  (was: Blocker)


> API Compatibility for org.wildfly.security.mechanism.MechanismUtil
> ------------------------------------------------------------------
>
>                 Key: ELY-1448
>                 URL: https://issues.jboss.org/browse/ELY-1448
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> Backwards compatibility has been broken on the public handleCallbacks methods so this needs to be fixed.
> However this class should not really be a public API, it has been picked up in the package as we have the AuthenticationMechanismException which does need to be public.
> The entire class should be deprecated and the impl moved to a private package.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:45:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:45:00 -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.94409.1512650700536@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-1436:
-------------------------------------

    Assignee: 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: Darran Lofthouse
>             Fix For: 1.2.0.Beta11
>
>
> 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 Dec  7 07:46:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:46:00 -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.94411.1512650760214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-1405:
-------------------------------------

    Assignee:     (was: Darran Lofthouse)


> 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
>             Fix For: 1.2.0.Beta11
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:47:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1386) <certificate-revocation-list
 /> should also support a URI and resource in addition to path.
In-Reply-To: <JIRA.12714964.1507288406000@Atlassian.JIRA>
References: <JIRA.12714964.1507288406000@Atlassian.JIRA>
	<JIRA.12714964.1507288406000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12714964.1507288406000.94419.1512650820463@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-1386:
-------------------------------------

    Assignee:     (was: Darran Lofthouse)


> <certificate-revocation-list /> should also support a URI and resource in addition to path.
> -------------------------------------------------------------------------------------------
>
>                 Key: ELY-1386
>                 URL: https://issues.jboss.org/browse/ELY-1386
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta11
>
>
> KeyStores can be loaded from a path, a URI, or as a resource - the certificate revocation list should be the same.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:49:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1370) CachingSecurityRealm and
 RealmIdentityCache missing TRACE loggin
In-Reply-To: <JIRA.12712605.1505920818000@Atlassian.JIRA>
References: <JIRA.12712605.1505920818000@Atlassian.JIRA>
	<JIRA.12712605.1505920818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712605.1505920818000.94446.1512650940092@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-1370:
-------------------------------------

    Assignee: Darran Lofthouse


> CachingSecurityRealm and RealmIdentityCache missing TRACE loggin
> ----------------------------------------------------------------
>
>                 Key: ELY-1370
>                 URL: https://issues.jboss.org/browse/ELY-1370
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Realms
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta11
>
>
> Where caching is in use there is no TRACE logging showing the activity in the cache.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:50:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1370) CachingSecurityRealm and
 RealmIdentityCache missing TRACE logging
In-Reply-To: <JIRA.12712605.1505920818000@Atlassian.JIRA>
References: <JIRA.12712605.1505920818000@Atlassian.JIRA>
	<JIRA.12712605.1505920818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712605.1505920818000.94449.1512651000194@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1370:
----------------------------------
    Summary: CachingSecurityRealm and RealmIdentityCache missing TRACE logging  (was: CachingSecurityRealm and RealmIdentityCache missing TRACE loggin)


> CachingSecurityRealm and RealmIdentityCache missing TRACE logging
> -----------------------------------------------------------------
>
>                 Key: ELY-1370
>                 URL: https://issues.jboss.org/browse/ELY-1370
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Realms
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta11
>
>
> Where caching is in use there is no TRACE logging showing the activity in the cache.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:51:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.94454.1512651060428@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-849:
------------------------------------

    Assignee:     (was: Darran Lofthouse)


> Rename setMechanismProperties to setSaslMechanismProperties
> -----------------------------------------------------------
>
>                 Key: ELY-849
>                 URL: https://issues.jboss.org/browse/ELY-849
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>
> If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties.
> We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:51:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.94457.1512651060510@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-849:
---------------------------------
    Fix Version/s: 1.2.0.Beta12
                       (was: 1.2.0.Beta11)


> Rename setMechanismProperties to setSaslMechanismProperties
> -----------------------------------------------------------
>
>                 Key: ELY-849
>                 URL: https://issues.jboss.org/browse/ELY-849
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>
> If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties.
> We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:51:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.94460.1512651060630@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-849:
---------------------------------
    Priority: Major  (was: Critical)


> Rename setMechanismProperties to setSaslMechanismProperties
> -----------------------------------------------------------
>
>                 Key: ELY-849
>                 URL: https://issues.jboss.org/browse/ELY-849
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties.
> We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:51:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.94463.1512651060694@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502941#comment-13502941 ] 

Darran Lofthouse commented on ELY-849:
--------------------------------------

If we do this now we will have to consider backwards compatibility.

> Rename setMechanismProperties to setSaslMechanismProperties
> -----------------------------------------------------------
>
>                 Key: ELY-849
>                 URL: https://issues.jboss.org/browse/ELY-849
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties.
> We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:57:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1428) Elytron provider has to be
 installed manually for key-store-ssl-certificate
In-Reply-To: <JIRA.12718553.1509356161000@Atlassian.JIRA>
References: <JIRA.12718553.1509356161000@Atlassian.JIRA>
	<JIRA.12718553.1509356161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718553.1509356161000.94507.1512651420667@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1428:
----------------------------------
    Component/s: Authentication Client


> Elytron provider has to be installed manually for key-store-ssl-certificate
> ---------------------------------------------------------------------------
>
>                 Key: ELY-1428
>                 URL: https://issues.jboss.org/browse/ELY-1428
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> Trying to configure ejb client 2-way TLS authentication with Elytron. I am getting "Invalid algorithm "clear" without use of programatically registering Elytron provider.
> {noformat}
> Security.addProvider(new WildFlyElytronProvider());
> {noformat}
> Specifying this in {{wildfly-config.xml}} doesn't help:
> {noformat}
> <providers>
>             <use-service-loader/>
> </providers>
> {noformat}
> Example of {{wildfly-config.xml}} where I need this when using it with EJB client:
> {code:xml}
> <configuration>
>     <authentication-client xmlns="urn:elytron:1.0">
>         <authentication-rules>
>             <rule use-configuration="default"/>
>         </authentication-rules>
>         <authentication-configurations>
>             <configuration name="default">
>                 <credentials>
>                     <key-store-reference key-store-name="client-keystore" alias="joe">
>                         <key-store-clear-password password="abcdef"/>
>                     </key-store-reference>
>                 </credentials>
>             </configuration>
>         </authentication-configurations>
>         <key-stores>
>             <key-store name="client-keystore" type="JKS">
>                 <file name="${keystore.path:src/main/resources/client.keystore}"/>
>                 <key-store-clear-password password="abcdef"/>
>             </key-store>
>             <key-store name="client-truststore" type="JKS">
>                 <file name="${truststore.path:src/main/resources/client.truststore}"/>
>             </key-store>
>         </key-stores>
>         <ssl-contexts>
>             <ssl-context name="client-ssl-context">
>                 <trust-store key-store-name="client-truststore"/>
>                 <key-store-ssl-certificate key-store-name="client-keystore" alias="joe">
>                     <key-store-clear-password password="abcdef"/>
>                 </key-store-ssl-certificate>
>             </ssl-context>
>         </ssl-contexts>
>         <ssl-context-rules>
>             <rule use-ssl-context="client-ssl-context"/>
>         </ssl-context-rules>
>     </authentication-client>
> </configuration>
> {code}
> Without installing the Elytron provider, the client will fail with this error:
> {noformat}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.wildfly.security.auth.client.AuthenticationContext.lambda$static$0(AuthenticationContext.java:49)
> 	at org.wildfly.common.context.ContextManager.getPrivileged(ContextManager.java:282)
> 	at org.wildfly.security.auth.client.AuthenticationContext.captureCurrent(AuthenticationContext.java:81)
> 	at org.wildfly.naming.client.ProviderEnvironment$1.get(ProviderEnvironment.java:89)
> 	at org.wildfly.naming.client.ProviderEnvironment$1.get(ProviderEnvironment.java:87)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.<init>(EJBClientInvocationContext.java:87)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:154)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
> 	at com.sun.proxy.$Proxy2.hello(Unknown Source)
> 	at client.Client.main(Client.java:21)
> Caused by: org.wildfly.security.auth.client.InvalidAuthenticationConfigurationException: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data
> 	at file:/home/jmartisk/Workspace/mock-artifacts/ejbclient/eap7.1-elytron-certificate-auth-with-two-way-ssl/client/target/classes/META-INF/wildfly-config.xml:9:87
> 	at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
> 	... 10 more
> Caused by: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data
> 	at file:/home/jmartisk/Workspace/mock-artifacts/ejbclient/eap7.1-elytron-certificate-auth-with-two-way-ssl/client/target/classes/META-INF/wildfly-config.xml:9:87
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1410)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$28(ElytronXmlParser.java:952)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$26(ElytronXmlParser.java:939)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$36(ElytronXmlParser.java:997)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$21(ElytronXmlParser.java:733)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$26(ElytronXmlParser.java:939)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$25(ElytronXmlParser.java:781)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$10(ElytronXmlParser.java:613)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$11(ElytronXmlParser.java:639)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:337)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:214)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:175)
> 	at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
> 	... 12 more
> Caused by: java.security.NoSuchAlgorithmException: ELY08028: Invalid algorithm "clear"
> 	at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121)
> 	at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:75)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1376)
> 	... 24 more
> {noformat}
> Using credential-store-reference clear-text cause similar error.
> There is example of clear passwords which works, so it will be problem of this specific elements:
> {code:xml}
> <authentication-client xmlns="urn:elytron:1.0">
>         <authentication-rules>
>             <rule use-configuration="default"/>
>         </authentication-rules>
>         <authentication-configurations>
>             <configuration name="default">
>                 <sasl-mechanism-selector selector="DIGEST-MD5"/>
>                 <set-user-name name="joe"/>
>                 <credentials>
>                     <clear-password password="joeIsAwesome2013!"/>
>                 </credentials>
>             </configuration>
>         </authentication-configurations>
>     </authentication-client>	
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 07:58:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 7 Dec 2017 07:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1428) Elytron provider has to be
 installed manually for key-store-ssl-certificate
In-Reply-To: <JIRA.12718553.1509356161000@Atlassian.JIRA>
References: <JIRA.12718553.1509356161000@Atlassian.JIRA>
	<JIRA.12718553.1509356161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718553.1509356161000.94515.1512651480177@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1428:
----------------------------------
    Fix Version/s: 1.2.0.Beta11


> Elytron provider has to be installed manually for key-store-ssl-certificate
> ---------------------------------------------------------------------------
>
>                 Key: ELY-1428
>                 URL: https://issues.jboss.org/browse/ELY-1428
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta11
>
>
> Trying to configure ejb client 2-way TLS authentication with Elytron. I am getting "Invalid algorithm "clear" without use of programatically registering Elytron provider.
> {noformat}
> Security.addProvider(new WildFlyElytronProvider());
> {noformat}
> Specifying this in {{wildfly-config.xml}} doesn't help:
> {noformat}
> <providers>
>             <use-service-loader/>
> </providers>
> {noformat}
> Example of {{wildfly-config.xml}} where I need this when using it with EJB client:
> {code:xml}
> <configuration>
>     <authentication-client xmlns="urn:elytron:1.0">
>         <authentication-rules>
>             <rule use-configuration="default"/>
>         </authentication-rules>
>         <authentication-configurations>
>             <configuration name="default">
>                 <credentials>
>                     <key-store-reference key-store-name="client-keystore" alias="joe">
>                         <key-store-clear-password password="abcdef"/>
>                     </key-store-reference>
>                 </credentials>
>             </configuration>
>         </authentication-configurations>
>         <key-stores>
>             <key-store name="client-keystore" type="JKS">
>                 <file name="${keystore.path:src/main/resources/client.keystore}"/>
>                 <key-store-clear-password password="abcdef"/>
>             </key-store>
>             <key-store name="client-truststore" type="JKS">
>                 <file name="${truststore.path:src/main/resources/client.truststore}"/>
>             </key-store>
>         </key-stores>
>         <ssl-contexts>
>             <ssl-context name="client-ssl-context">
>                 <trust-store key-store-name="client-truststore"/>
>                 <key-store-ssl-certificate key-store-name="client-keystore" alias="joe">
>                     <key-store-clear-password password="abcdef"/>
>                 </key-store-ssl-certificate>
>             </ssl-context>
>         </ssl-contexts>
>         <ssl-context-rules>
>             <rule use-ssl-context="client-ssl-context"/>
>         </ssl-context-rules>
>     </authentication-client>
> </configuration>
> {code}
> Without installing the Elytron provider, the client will fail with this error:
> {noformat}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.wildfly.security.auth.client.AuthenticationContext.lambda$static$0(AuthenticationContext.java:49)
> 	at org.wildfly.common.context.ContextManager.getPrivileged(ContextManager.java:282)
> 	at org.wildfly.security.auth.client.AuthenticationContext.captureCurrent(AuthenticationContext.java:81)
> 	at org.wildfly.naming.client.ProviderEnvironment$1.get(ProviderEnvironment.java:89)
> 	at org.wildfly.naming.client.ProviderEnvironment$1.get(ProviderEnvironment.java:87)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.<init>(EJBClientInvocationContext.java:87)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:154)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
> 	at com.sun.proxy.$Proxy2.hello(Unknown Source)
> 	at client.Client.main(Client.java:21)
> Caused by: org.wildfly.security.auth.client.InvalidAuthenticationConfigurationException: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data
> 	at file:/home/jmartisk/Workspace/mock-artifacts/ejbclient/eap7.1-elytron-certificate-auth-with-two-way-ssl/client/target/classes/META-INF/wildfly-config.xml:9:87
> 	at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
> 	... 10 more
> Caused by: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data
> 	at file:/home/jmartisk/Workspace/mock-artifacts/ejbclient/eap7.1-elytron-certificate-auth-with-two-way-ssl/client/target/classes/META-INF/wildfly-config.xml:9:87
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1410)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$28(ElytronXmlParser.java:952)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$26(ElytronXmlParser.java:939)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$36(ElytronXmlParser.java:997)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$21(ElytronXmlParser.java:733)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$26(ElytronXmlParser.java:939)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$25(ElytronXmlParser.java:781)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$10(ElytronXmlParser.java:613)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$11(ElytronXmlParser.java:639)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:337)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:214)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:175)
> 	at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
> 	... 12 more
> Caused by: java.security.NoSuchAlgorithmException: ELY08028: Invalid algorithm "clear"
> 	at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121)
> 	at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:75)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1376)
> 	... 24 more
> {noformat}
> Using credential-store-reference clear-text cause similar error.
> There is example of clear passwords which works, so it will be problem of this specific elements:
> {code:xml}
> <authentication-client xmlns="urn:elytron:1.0">
>         <authentication-rules>
>             <rule use-configuration="default"/>
>         </authentication-rules>
>         <authentication-configurations>
>             <configuration name="default">
>                 <sasl-mechanism-selector selector="DIGEST-MD5"/>
>                 <set-user-name name="joe"/>
>                 <credentials>
>                     <clear-password password="joeIsAwesome2013!"/>
>                 </credentials>
>             </configuration>
>         </authentication-configurations>
>     </authentication-client>	
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 08:09:00 2017
From: issues at jboss.org (Dennis Gesker (JIRA))
Date: Thu, 7 Dec 2017 08:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7524) Add Hibernate-Spatial to
 WildFly Feature Pack
In-Reply-To: <JIRA.12660230.1478620902000@Atlassian.JIRA>
References: <JIRA.12660230.1478620902000@Atlassian.JIRA>
	<JIRA.12660230.1478620902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660230.1478620902000.94566.1512652140327@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502951#comment-13502951 ] 

Dennis Gesker commented on WFLY-7524:
-------------------------------------

Apologies, [Sanne Grinovero |https://issues.jboss.org/secure/ViewProfile.jspa?name=sannegrinovero] and [Kabir Khan|https://issues.jboss.org/secure/ViewProfile.jspa?name=kabirkhan] I'm still learning how the project is organized. 

This is what I'm running into...
In my build (gradle) I keep and entry similar to...
 
providedCompile 'org.wildfly:wildfly-feature-pack:11.0.0.Final'  so I have all of these packages from the maven repositories. So, the wildfly-feature-pack is SUPER convenient. It would be great if everything needed for GIS / Spatial work was in that package.

But, I also added a related link [WFLY-7523|https://issues.jboss.org/browse/WFLY-7523] as for this to really be a useful add I would be very helpful to have the GIS / Spatial portions of Hibernate shipped with the server. Right now I've got to add them each time I try a new version of WildFly.

I've just made the jump to 11 to take Elytron for a spin. But, even if adding Spatial / GIS for 12 would be awesome and very useful.




> Add Hibernate-Spatial to WildFly Feature Pack
> ---------------------------------------------
>
>                 Key: WFLY-7524
>                 URL: https://issues.jboss.org/browse/WFLY-7524
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 10.1.0.Final
>         Environment: Linux / OpenJDK 8 / WildFly 10.1.0.Final
>            Reporter: Dennis Gesker
>            Assignee: Jason Greene
>              Labels: wildfly-feature-pack
>
> If possible kindly add jars need to make use of hibernate-spatial to WildFly-Feature-Pack
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> BTW, thank you for this package. It saves a HUGE amount of time with dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 08:10:00 2017
From: issues at jboss.org (Dennis Gesker (JIRA))
Date: Thu, 7 Dec 2017 08:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7524) Add Hibernate-Spatial to
 WildFly Feature Pack
In-Reply-To: <JIRA.12660230.1478620902000@Atlassian.JIRA>
References: <JIRA.12660230.1478620902000@Atlassian.JIRA>
	<JIRA.12660230.1478620902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660230.1478620902000.94579.1512652200325@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Gesker updated WFLY-7524:
--------------------------------
    Affects Version/s: 11.0.0.Final
                       12.0.0.Alpha1
                           (was: 10.1.0.Final)


> Add Hibernate-Spatial to WildFly Feature Pack
> ---------------------------------------------
>
>                 Key: WFLY-7524
>                 URL: https://issues.jboss.org/browse/WFLY-7524
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 11.0.0.Final, 12.0.0.Alpha1
>         Environment: Linux / OpenJDK 8 / WildFly 10.1.0.Final
>            Reporter: Dennis Gesker
>            Assignee: Jason Greene
>              Labels: wildfly-feature-pack
>
> If possible kindly add jars need to make use of hibernate-spatial to WildFly-Feature-Pack
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> BTW, thank you for this package. It saves a HUGE amount of time with dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 08:10:00 2017
From: issues at jboss.org (Dennis Gesker (JIRA))
Date: Thu, 7 Dec 2017 08:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7523) Add hibernate-spatial to
	hibernate module
In-Reply-To: <JIRA.12660227.1478620480000@Atlassian.JIRA>
References: <JIRA.12660227.1478620480000@Atlassian.JIRA>
	<JIRA.12660227.1478620480000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660227.1478620480000.94580.1512652200342@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Gesker updated WFLY-7523:
--------------------------------
    Affects Version/s: 11.0.0.Final
                       12.0.0.Alpha1
                           (was: 10.1.0.Final)


> Add hibernate-spatial to hibernate module
> -----------------------------------------
>
>                 Key: WFLY-7523
>                 URL: https://issues.jboss.org/browse/WFLY-7523
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 11.0.0.Final, 12.0.0.Alpha1
>         Environment: Linux / OpenJDK 8 / Wildfly 10.1.0.Final
>            Reporter: Dennis Gesker
>              Labels: hibernate_persistance_layer
>
> The use of GIS extensions is becoming more prevalent. It would be very helpful if org.hibernate:hibernate-spatial was added to the the hibernate module.
> hibernate-spatial SEEMS to also require the following jars/packages :
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> So, jars would need to be added to modules/system/layers/base/org/hibernate/main and associated <resource-root> tags in module.xml
> I believe  <dependencies> would also require <module name="org.slf4j"/> entry
> Note: The "Create Issue" page defaulted this item to "Major" but it is labeled as (FOR USE BY COMMITTERS ONLY) so I did not change it. I would have chosen "Minor" as this would be really useful but of course doesn't break or stop anything.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 08:11:00 2017
From: issues at jboss.org (Dennis Gesker (JIRA))
Date: Thu, 7 Dec 2017 08:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7523) Add hibernate-spatial to
	hibernate module
In-Reply-To: <JIRA.12660227.1478620480000@Atlassian.JIRA>
References: <JIRA.12660227.1478620480000@Atlassian.JIRA>
	<JIRA.12660227.1478620480000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660227.1478620480000.94586.1512652260367@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Gesker updated WFLY-7523:
--------------------------------
    Environment: Linux / OpenJDK 8 / Wildfly 11.0.0.Final  (was: Linux / OpenJDK 8 / Wildfly 10.1.0.Final)


> Add hibernate-spatial to hibernate module
> -----------------------------------------
>
>                 Key: WFLY-7523
>                 URL: https://issues.jboss.org/browse/WFLY-7523
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 11.0.0.Final, 12.0.0.Alpha1
>         Environment: Linux / OpenJDK 8 / Wildfly 11.0.0.Final
>            Reporter: Dennis Gesker
>              Labels: hibernate_persistance_layer
>
> The use of GIS extensions is becoming more prevalent. It would be very helpful if org.hibernate:hibernate-spatial was added to the the hibernate module.
> hibernate-spatial SEEMS to also require the following jars/packages :
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> So, jars would need to be added to modules/system/layers/base/org/hibernate/main and associated <resource-root> tags in module.xml
> I believe  <dependencies> would also require <module name="org.slf4j"/> entry
> Note: The "Create Issue" page defaulted this item to "Major" but it is labeled as (FOR USE BY COMMITTERS ONLY) so I did not change it. I would have chosen "Minor" as this would be really useful but of course doesn't break or stop anything.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 08:11:00 2017
From: issues at jboss.org (Dennis Gesker (JIRA))
Date: Thu, 7 Dec 2017 08:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7524) Add Hibernate-Spatial to
 WildFly Feature Pack
In-Reply-To: <JIRA.12660230.1478620902000@Atlassian.JIRA>
References: <JIRA.12660230.1478620902000@Atlassian.JIRA>
	<JIRA.12660230.1478620902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660230.1478620902000.94590.1512652260480@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Gesker updated WFLY-7524:
--------------------------------
    Environment: Linux / OpenJDK 8 / Wildfly 11.0.0.Final  (was: Linux / OpenJDK 8 / WildFly 10.1.0.Final)


> Add Hibernate-Spatial to WildFly Feature Pack
> ---------------------------------------------
>
>                 Key: WFLY-7524
>                 URL: https://issues.jboss.org/browse/WFLY-7524
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 11.0.0.Final, 12.0.0.Alpha1
>         Environment: Linux / OpenJDK 8 / Wildfly 11.0.0.Final
>            Reporter: Dennis Gesker
>            Assignee: Jason Greene
>              Labels: wildfly-feature-pack
>
> If possible kindly add jars need to make use of hibernate-spatial to WildFly-Feature-Pack
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> BTW, thank you for this package. It saves a HUGE amount of time with dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 08:13:01 2017
From: issues at jboss.org (Dennis Gesker (JIRA))
Date: Thu, 7 Dec 2017 08:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7524) Add Hibernate-Spatial to
 WildFly Feature Pack
In-Reply-To: <JIRA.12660230.1478620902000@Atlassian.JIRA>
References: <JIRA.12660230.1478620902000@Atlassian.JIRA>
	<JIRA.12660230.1478620902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660230.1478620902000.94610.1512652381089@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502951#comment-13502951 ] 

Dennis Gesker edited comment on WFLY-7524 at 12/7/17 8:12 AM:
--------------------------------------------------------------

Apologies, [Sanne Grinovero |https://issues.jboss.org/secure/ViewProfile.jspa?name=sannegrinovero] and [Kabir Khan|https://issues.jboss.org/secure/ViewProfile.jspa?name=kabirkhan] I'm still learning how the project is organized. 

This is what I'm running into...
In my build (gradle) I keep and entry similar to...
 
providedCompile 'org.wildfly:wildfly-feature-pack:11.0.0.Final'  so I have all of these packages from the maven repositories. So, the wildfly-feature-pack is SUPER convenient. It would be great if everything needed for GIS / Spatial work was in that package.

But, I also added a related issue [WFLY-7523|https://issues.jboss.org/browse/WFLY-7523] as for this to really be a useful it would be very helpful to have the GIS / Spatial portions of Hibernate shipped with the server. Right now I've got to add them each time I try a new version of WildFly.

I've just made the jump to 11 to take Elytron for a spin. But, even if adding Spatial / GIS for 12 would be awesome and very useful.





was (Author: gesker):
Apologies, [Sanne Grinovero |https://issues.jboss.org/secure/ViewProfile.jspa?name=sannegrinovero] and [Kabir Khan|https://issues.jboss.org/secure/ViewProfile.jspa?name=kabirkhan] I'm still learning how the project is organized. 

This is what I'm running into...
In my build (gradle) I keep and entry similar to...
 
providedCompile 'org.wildfly:wildfly-feature-pack:11.0.0.Final'  so I have all of these packages from the maven repositories. So, the wildfly-feature-pack is SUPER convenient. It would be great if everything needed for GIS / Spatial work was in that package.

But, I also added a related link [WFLY-7523|https://issues.jboss.org/browse/WFLY-7523] as for this to really be a useful add I would be very helpful to have the GIS / Spatial portions of Hibernate shipped with the server. Right now I've got to add them each time I try a new version of WildFly.

I've just made the jump to 11 to take Elytron for a spin. But, even if adding Spatial / GIS for 12 would be awesome and very useful.




> Add Hibernate-Spatial to WildFly Feature Pack
> ---------------------------------------------
>
>                 Key: WFLY-7524
>                 URL: https://issues.jboss.org/browse/WFLY-7524
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 11.0.0.Final, 12.0.0.Alpha1
>         Environment: Linux / OpenJDK 8 / Wildfly 11.0.0.Final
>            Reporter: Dennis Gesker
>            Assignee: Jason Greene
>              Labels: wildfly-feature-pack
>
> If possible kindly add jars need to make use of hibernate-spatial to WildFly-Feature-Pack
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> BTW, thank you for this package. It saves a HUGE amount of time with dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 08:14:00 2017
From: issues at jboss.org (Dennis Gesker (JIRA))
Date: Thu, 7 Dec 2017 08:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7523) Add hibernate-spatial to
	hibernate module
In-Reply-To: <JIRA.12660227.1478620480000@Atlassian.JIRA>
References: <JIRA.12660227.1478620480000@Atlassian.JIRA>
	<JIRA.12660227.1478620480000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660227.1478620480000.94611.1512652440138@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Gesker updated WFLY-7523:
--------------------------------
    Affects Version/s: 10.1.0.Final


> Add hibernate-spatial to hibernate module
> -----------------------------------------
>
>                 Key: WFLY-7523
>                 URL: https://issues.jboss.org/browse/WFLY-7523
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 10.1.0.Final, 11.0.0.Final, 12.0.0.Alpha1
>         Environment: Linux / OpenJDK 8 / Wildfly 11.0.0.Final
>            Reporter: Dennis Gesker
>              Labels: hibernate_persistance_layer
>
> The use of GIS extensions is becoming more prevalent. It would be very helpful if org.hibernate:hibernate-spatial was added to the the hibernate module.
> hibernate-spatial SEEMS to also require the following jars/packages :
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> So, jars would need to be added to modules/system/layers/base/org/hibernate/main and associated <resource-root> tags in module.xml
> I believe  <dependencies> would also require <module name="org.slf4j"/> entry
> Note: The "Create Issue" page defaulted this item to "Major" but it is labeled as (FOR USE BY COMMITTERS ONLY) so I did not change it. I would have chosen "Minor" as this would be really useful but of course doesn't break or stop anything.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 08:47:00 2017
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 7 Dec 2017 08:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-183) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723786.1512572196000@Atlassian.JIRA>
References: <JIRA.12723786.1512572196000@Atlassian.JIRA>
	<JIRA.12723786.1512572196000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723786.1512572196000.94841.1512654420345@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502971#comment-13502971 ] 

Scott Marlow commented on JBEE-183:
-----------------------------------

Might it be that org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString is the victim of 'mBypassCache' being false initially (so we skip call to 'createExpressionStringMap') but later being true (likely from activity on different thread) at the time that we reach the subsequent use of (null) createExpressionStringMap.

Could we preallocate the sCachedExpressionStrings?

> NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBEE-183
>                 URL: https://issues.jboss.org/browse/JBEE-183
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>         Environment: - JBoss EAP 7.0.8
> - jboss-jstl-api_1.2_spec-1.1.3.Final
>            Reporter: Masafumi Miura
>            Assignee: Tomas Hofman
>         Attachments: byteman-script.btm, example.zip
>
>
> The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 
> Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)
> {code}
> ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
>     ...(snip)...
>     ...
> Caused by: java.lang.NullPointerException
>     at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
>     at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
>     at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
>     at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
>     at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
>     at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
>     at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     ... 61 more
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277
> {code}
> 252     public Object parseExpressionString(String pExpressionString)
> 253             throws ELException {
> 254         // See if it's an empty String
> 255         if (pExpressionString.length() == 0) {
> 256             return "";
> 257         }
> 258
> 259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
> 260             createExpressionStringMap();
> 261         }
> 262
> 263         // See if it's in the cache
> 264         Object ret =
> 265                 mBypassCache ?
> 266                         null :
> 267                         sCachedExpressionStrings.get(pExpressionString);
> 268
> 269         if (ret == null) {
> 270             // Parse the expression
> 271             Reader r = new StringReader(pExpressionString);
> 272             ELParser parser = new ELParser(r);
> 273             try {
> 274                 ret = parser.ExpressionString();
> 275                 if (!mBypassCache) {
> 276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
> 277                 }
> 278             }
> 279             catch (ParseException exc) {
> 280                 throw new ELException
> 281                         (formatParseException(pExpressionString,
> 282                                 exc));
> 283             }
> 284             catch (TokenMgrError exc) {
> 285                 // Note - this should never be reached, since the parser is
> 286                 // constructed to tokenize any input (illegal inputs get
> 287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
> 288                 // <ILLEGAL_CHARACTER>
> 289                 throw new ELException(exc.getMessage());
> 290             }
> 291         }
> 292         return ret;
> 293     }
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71
> {code}
> ~~~
>  51     /**
>  52      * The singleton instance of the evaluator *
>  53      */
>  54     static ELEvaluator sEvaluator =
>  55             new ELEvaluator
>  56                     (new JSTLVariableResolver());
>  :
>  62     /**
>  63      * Translation time validation of an attribute value.  This method
>  64      * will return a null String if the attribute value is valid;
>  65      * otherwise an error message.
>  66      */
>  67     public String validate(String pAttributeName,
>  68                            String pAttributeValue) {
>  69         try {
>  70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
>  71             sEvaluator.parseExpressionString(pAttributeValue);
>  72             sEvaluator.setBypassCache(false);
>  73             return null;
>  74         }
>  75         catch (ELException exc) {
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 08:47:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 7 Dec 2017 08:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7298) Testsuite IO ops housekeeping
In-Reply-To: <JIRA.12654467.1476283813000@Atlassian.JIRA>
References: <JIRA.12654467.1476283813000@Atlassian.JIRA>
	<JIRA.12654467.1476283813000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654467.1476283813000.94845.1512654420502@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reopened WFLY-7298:
-------------------------------


> Testsuite IO ops housekeeping
> -----------------------------
>
>                 Key: WFLY-7298
>                 URL: https://issues.jboss.org/browse/WFLY-7298
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 11.0.0.Alpha1
>
>
> Do some needed housekeeping of testsuite



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 08:49:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 7 Dec 2017 08:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7298) Testsuite IO ops housekeeping
In-Reply-To: <JIRA.12654467.1476283813000@Atlassian.JIRA>
References: <JIRA.12654467.1476283813000@Atlassian.JIRA>
	<JIRA.12654467.1476283813000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654467.1476283813000.94863.1512654540908@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7298:
------------------------------
    Fix Version/s: 12.0.0.Alpha1
                       (was: 11.0.0.Alpha1)


> Testsuite IO ops housekeeping
> -----------------------------
>
>                 Key: WFLY-7298
>                 URL: https://issues.jboss.org/browse/WFLY-7298
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 12.0.0.Alpha1
>
>
> Do some needed housekeeping of testsuite



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 09:23:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 7 Dec 2017 09:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1459) Move byte and codepoint
 iterators to WildFly Common
In-Reply-To: <JIRA.12723806.1512575358000@Atlassian.JIRA>
References: <JIRA.12723806.1512575358000@Atlassian.JIRA>
	<JIRA.12723806.1512575358000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723806.1512575358000.95049.1512656580373@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned ELY-1459:
--------------------------------

    Assignee: David Lloyd


> Move byte and codepoint iterators to WildFly Common
> ---------------------------------------------------
>
>                 Key: ELY-1459
>                 URL: https://issues.jboss.org/browse/ELY-1459
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Utils
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>
> This is the partner issue to WFCOM-25.
> There is a need or desire to open up the byte/code point iteration API, but the natural tension is that it is not really security related.  At the same time, this kind of code is duplicated in a few other places.  Moving these classes to WildFly Common would solve several problems at once.
> This issue should serve as a point of discussion for this idea.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 09:40:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Thu, 7 Dec 2017 09:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6892) Access logging for EJBs
In-Reply-To: <JIRA.12641130.1469724984000@Atlassian.JIRA>
References: <JIRA.12641130.1469724984000@Atlassian.JIRA>
	<JIRA.12641130.1469724984000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641130.1469724984000.95127.1512657600483@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone reassigned WFLY-6892:
------------------------------------

    Assignee: Flavia Rainone


> Access logging for EJBs
> -----------------------
>
>                 Key: WFLY-6892
>                 URL: https://issues.jboss.org/browse/WFLY-6892
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>    Affects Versions: 10.0.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Flavia Rainone
>              Labels: affects_elytron
>
> Access logging for EJB requests similar to Web access logging would be very useful.
> Possibly something like:
> {code}
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] [invocation id] Request Received ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Starting Invocation ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Finished Invocation ...
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 09:45:01 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 7 Dec 2017 09:45:01 -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.95148.1512657901005@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise reassigned WFCORE-3450:
--------------------------------------------

    Assignee: 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: Jean-Francois Denise
>
> 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  Thu Dec  7 09:52:01 2017
From: issues at jboss.org (Amy Glass (JIRA))
Date: Thu, 7 Dec 2017 09:52: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.95215.1512658321124@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amy Glass updated DROOLS-2160:
------------------------------
    Labels: UX  (was: )


> 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: Toni Rikkola
>              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 Dec  7 10:32:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 7 Dec 2017 10:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1460) External CS,
 PKCS11 can't be configured with externalPath
In-Reply-To: <JIRA.12723972.1512660535000@Atlassian.JIRA>
References: <JIRA.12723972.1512660535000@Atlassian.JIRA>
	<JIRA.12723972.1512660535000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723972.1512660535000.95515.1512660720115@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved JBEAP-13929 to ELY-1460:
--------------------------------------------

              Project: WildFly Elytron  (was: JBoss Enterprise Application Platform)
                  Key: ELY-1460  (was: JBEAP-13929)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: KeyStores
                           (was: Security)
    Affects Version/s: 1.2.0.Beta10
                           (was: 7.1.0.CR2)


> External CS, PKCS11 can't be configured with externalPath 
> ----------------------------------------------------------
>
>                 Key: ELY-1460
>                 URL: https://issues.jboss.org/browse/ELY-1460
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: KeyStores
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Ilia Vassilev
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 	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.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> 	at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> 	... 5 more
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 	at java.nio.file.Files.newByteChannel(Files.java:361)
> 	at java.nio.file.Files.newByteChannel(Files.java:407)
> 	at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> 	at java.nio.file.Files.newInputStream(Files.java:152)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> 	... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
>     Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
>     Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
>     private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
>         KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
>         keyStore = getKeyStoreInstance("JCEKS");
>         externalStorage = new ExternalStorage();
>         try {
>             final char[] storePassword = getStorePassword(protectionParameter);
>             if (keyContainingKeyStoreLocation != null) {
>                 try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
>                     keyContainingKeyStore.load(is, storePassword);
>                 }
>             } else {
>                 // keystore without file (e.g. PKCS11)
>                 synchronized (EmptyProvider.getInstance()) {
>                     keyContainingKeyStore.load(null, storePassword);
>                 }
>             }
>             externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
>         } catch(IOException | GeneralSecurityException e) {
>             throw log.cannotInitializeCredentialStore(e);
>         }
>     }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 10:34:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 7 Dec 2017 10:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9601) NullPointerException in build
 during checkstyle
In-Reply-To: <JIRA.12723975.1512660771000@Atlassian.JIRA>
References: <JIRA.12723975.1512660771000@Atlassian.JIRA>
	<JIRA.12723975.1512660771000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723975.1512660771000.95542.1512660840278@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved JBEAP-13930 to WFLY-9601:
-------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-9601  (was: JBEAP-13930)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Build System
                     (was: Build System)


> NullPointerException in build during checkstyle
> -----------------------------------------------
>
>                 Key: WFLY-9601
>                 URL: https://issues.jboss.org/browse/WFLY-9601
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>         Environment: Customized :P
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Critical
>
> {code}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle (check-style) on project wildfly-naming: Execution check-style of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle failed. NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle (check-style) on project wildfly-naming: Execution check-style of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle failed.
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> 	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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> 	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.apache.maven.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:39)
> 	at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:122)
> 	at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:50)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution check-style of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle failed.
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> 	... 27 more
> Caused by: java.lang.NullPointerException
> 	at com.puppycrawl.tools.checkstyle.checks.SuppressWarningsHolder.isSuppressed(SuppressWarningsHolder.java:200)
> 	at com.puppycrawl.tools.checkstyle.filters.SuppressWarningsFilter.accept(SuppressWarningsFilter.java:38)
> 	at com.puppycrawl.tools.checkstyle.api.FilterSet.accept(FilterSet.java:88)
> 	at com.puppycrawl.tools.checkstyle.Checker.fireErrors(Checker.java:358)
> 	at com.puppycrawl.tools.checkstyle.Checker.process(Checker.java:276)
> 	at org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:252)
> 	at org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:473)
> 	at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:154)
> 	at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> 	at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:143)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> 	... 28 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 10:39:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 7 Dec 2017 10:39: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.95569.1512661140530@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502673#comment-13502673 ] 

Jan Kalina edited comment on ELY-283 at 12/7/17 10:38 AM:
----------------------------------------------------------

Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...

{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/-1696122173
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
    Calling Error = 0
    Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
    Supplementary Status Bits = 0
minor = -1696122173 (signed dec) = 2598845123 (unsigned dec) =  9AE73AC3 (hex)
{code}


was (Author: honza889):
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...

{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/69206038
c/r/s = 0/13/0 
{code}
{code}
major = d0000 = 0 / 13 / 0
    Calling Error = 0
    Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
    Supplementary Status Bits = 0
minor = 69206038 (dec) =  04200016 (hex)
{code}

> 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
>
>
> 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 Dec  7 11:13:00 2017
From: issues at jboss.org (Martin Mazanek (JIRA))
Date: Thu, 7 Dec 2017 11:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration
 uniqueness enhancements
In-Reply-To: <JIRA.12675329.1486478892000@Atlassian.JIRA>
References: <JIRA.12675329.1486478892000@Atlassian.JIRA>
	<JIRA.12675329.1486478892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675329.1486478892000.95703.1512663180263@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503070#comment-13503070 ] 

Martin Mazanek commented on ELY-929:
------------------------------------

The JavaDoc has already been added, the rest not.
What is the purpose of capturing instances of Supplier-driven components? 

> AuthenticationConfiguration uniqueness enhancements
> ---------------------------------------------------
>
>                 Key: ELY-929
>                 URL: https://issues.jboss.org/browse/ELY-929
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: David Lloyd
>             Fix For: 1.2.0.Beta12
>
>
> Apply some enhancements to AuthenticationConfiguration uniqueness.
> * Add admonishing JavaDoc to {{useCallbackHandler}} to point out the importance of per-identity uniqueness of the callback handler
> The following also may be possible and useful:
> * Modify the {{AuthenticationConfiguration}} process to capture instances for {{Supplier}}-driven components at the time the configuration is used via the {{AuthenticationContextConfigurationClient}}
> * Add a variation of {{useCallbackHandler}} which accepts a {{Supplier<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 11:34:00 2017
From: issues at jboss.org (Prachi Yadav (JIRA))
Date: Thu, 7 Dec 2017 11:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-207) Define set of acceptance
	tests
In-Reply-To: <JIRA.12723347.1512402747000@Atlassian.JIRA>
References: <JIRA.12723347.1512402747000@Atlassian.JIRA>
	<JIRA.12723347.1512402747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723347.1512402747000.95854.1512664440273@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503088#comment-13503088 ] 

Prachi Yadav commented on HAWKULARQE-207:
-----------------------------------------

http://etherpad.corp.redhat.com/HAWKULARQE-207

> Define set of acceptance tests
> ------------------------------
>
>                 Key: HAWKULARQE-207
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-207
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Filip Brychta
>            Assignee: Prachi Yadav
>            Priority: Blocker
>
> We need a set of cases which are considered to be "must work" which will be run every time before a release.
> Example from JON:
> - ssl configuration was not part of such suite and because of that one ugly issue was missed which resulted in unreachable agents after upgrade and critical hot-fix
> Following should be done:
> * define those cases for each area
> * check that those cases are created in polarion
> * set the highest possible severity for those cases
> * define test run which will contain all those cases for each release
> * automate as much as possible
> * regularly check and update the suite with new features



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 11:40:00 2017
From: issues at jboss.org (Martin Mazanek (JIRA))
Date: Thu, 7 Dec 2017 11:40: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.95875.1512664800336@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503091#comment-13503091 ] 

Martin Mazanek commented on ELY-839:
------------------------------------

I think this can be closed

> 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
>
> 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 Dec  7 12:19:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 7 Dec 2017 12:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9593) Add clustering externalizers
 for InetAddress and InetSocketAddress
In-Reply-To: <JIRA.12723366.1512407521000@Atlassian.JIRA>
References: <JIRA.12723366.1512407521000@Atlassian.JIRA>
	<JIRA.12723366.1512407521000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723366.1512407521000.96035.1512667140295@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-9593:
-----------------------------
    Fix Version/s: 12.0.0.Alpha1
                       (was: 11.0.0.Final)


> Add clustering externalizers for InetAddress and InetSocketAddress
> ------------------------------------------------------------------
>
>                 Key: WFLY-9593
>                 URL: https://issues.jboss.org/browse/WFLY-9593
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 12.0.0.Alpha1
>
>
> InetAddress can be marshalled as a fixed sized array depending on whether the address is IPv4 or IPv6, which can be determined by the implementation class.
> InetSocketAddress can marshal its address using the InetAddress externalizer, and its port as an unsigned short.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 12:30:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 7 Dec 2017 12:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3367) Add note to elytron
 attributes that affects EAP configuration globally
In-Reply-To: <JIRA.12717280.1508423429000@Atlassian.JIRA>
References: <JIRA.12717280.1508423429000@Atlassian.JIRA>
	<JIRA.12717280.1508423429000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717280.1508423429000.96082.1512667800446@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed WFCORE-3367.
------------------------------
    Resolution: Rejected


As this change as requested more discussion and considerations then appropriate such minor improvement, rejected.

> Add note to elytron attributes that affects EAP configuration globally
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-3367
>                 URL: https://issues.jboss.org/browse/WFCORE-3367
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 3.0.6.Final
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Minor
>
> There are some attributes in elytron subsystem which have global effect on EAP server state even in case elytron security is not utilized in any way. Those are (at least):
> * disallowed-providers
> * final-providers
> * initial-providers
> We should put some note in description of those attributes that they have global effect on EAP server and take effect even in cases elytron security is not utilized anyhow. Reason is that it might be a little confusing for customers to find and configure these attributes in elytron subsystem even in case they use just legacy security-realm. One would expect that when something is configured in elytron subsystem it has not take effect unless explicitely referenced or used (because we still have also legacy security-realm based security). It is not a perfect state/UX but as Elytron is supposed to become a common and only place for server security configuration it is understandable that all new security related things are being put there.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 12:41:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 7 Dec 2017 12:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2240) Log a warning if no binding
 port in TCP is provided
In-Reply-To: <JIRA.12723889.1512639117000@Atlassian.JIRA>
References: <JIRA.12723889.1512639117000@Atlassian.JIRA>
	<JIRA.12723889.1512639117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723889.1512639117000.96118.1512668460357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2240:
---------------------------
    Fix Version/s: 4.0.10


> Log a warning if no binding port in TCP is provided
> ---------------------------------------------------
>
>                 Key: JGRP-2240
>                 URL: https://issues.jboss.org/browse/JGRP-2240
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 4.0.9
>            Reporter: andrea tarocchi
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0.10
>
>
> If a bind port is not defined and you don't bind (for some reason) to the default one, log a warning.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 12:46:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 7 Dec 2017 12:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-163) Monthly file rotation will
 continually overwrite the rotated log file
In-Reply-To: <JIRA.12700917.1499442351000@Atlassian.JIRA>
References: <JIRA.12700917.1499442351000@Atlassian.JIRA>
	<JIRA.12700917.1499442351000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12700917.1499442351000.96141.1512668760441@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGMGR-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503117#comment-13503117 ] 

RH Bugzilla Integration commented on LOGMGR-163:
------------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1468746|https://bugzilla.redhat.com/show_bug.cgi?id=1468746] from VERIFIED to CLOSED

> Monthly file rotation will continually overwrite the rotated log file
> ---------------------------------------------------------------------
>
>                 Key: LOGMGR-163
>                 URL: https://issues.jboss.org/browse/LOGMGR-163
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Blocker
>             Fix For: 1.1.2.CR1, 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.8.Final, 2.0.7.Final, 2.1.0.Alpha2
>
>
> When the next rollover time is calculated a {{java.util.Calendar}} is used. When rotated monthly the day of the week is set to 0 and 1 month is added. This causes the calendar to be set to the last day of the current month.
> On the last day of the month this also causes the file to continually rotate with each log message written, overwriting the previous log message.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 12:56:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 7 Dec 2017 12:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9598) Clustering Testsuite 2.0: CLI, no ant,
 no XSLT, 3-node DIST testing
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.96158.1512669360203@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  (was: Clustering Testsuite 2.0: no ant, CLI, 3-node DIST testing)


> Clustering Testsuite 2.0: CLI, no ant, no XSLT, 3-node DIST testing
> -------------------------------------------------------------------
>
>                 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
>
>
> For starters, move the testsuite away from using XSLT and just rely on the CLI scripts. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 14:26:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Dec 2017 14:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9602) Smarter range validation
	error messages
In-Reply-To: <JIRA.12724006.1512674708000@Atlassian.JIRA>
References: <JIRA.12724006.1512674708000@Atlassian.JIRA>
	<JIRA.12724006.1512674708172@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724006.1512674708000.96387.1512674760074@Atlassian.JIRA>

Brian Stansberry created WFLY-9602:
--------------------------------------

             Summary: Smarter range validation error messages
                 Key: WFLY-9602
                 URL: https://issues.jboss.org/browse/WFLY-9602
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Priority: Minor


A message like this is kind of silly: "Value must be between 0 and 9007199254740991".

Smarter would be the ParameterValidator code that detects the message checking if the range max is Integer.MAX_INT (for an int) or Long.MAX_LONG (for a long) and if the bad value is below the max, just saying the equivalent of "Value must be greater than %d".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec  7 18:55:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 7 Dec 2017 18:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1226) undeploying disabled
 deployment stops service for same runtime-name in DeploymentUndeployHandler
In-Reply-To: <JIRA.12596678.1450168528000@Atlassian.JIRA>
References: <JIRA.12596678.1450168528000@Atlassian.JIRA>
	<JIRA.12596678.1450168528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12596678.1450168528000.97424.1512690900135@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503185#comment-13503185 ] 

RH Bugzilla Integration commented on WFCORE-1226:
-------------------------------------------------

Abhijit humbe <abhumbe at redhat.com> changed the Status of [bug 1280262|https://bugzilla.redhat.com/show_bug.cgi?id=1280262] from NEW to CLOSED

> undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler 
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1226
>                 URL: https://issues.jboss.org/browse/WFCORE-1226
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.4.Final
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>             Fix For: 2.0.6.Final
>
>         Attachments: WFCORE-1226-wildflytest.patch, WFCORE-1226.patch
>
>
> {noformat}
> 1. Start EAP 6.4.4 in domain mode and deploy application using following CLI command:
> ~~
> [domain at localhost:9999 /] deploy /Applications/WebApp-1.war --server-groups=main-server-group --name=WebApp-1.war --runtime-name=WebApp-1.war
> ~~~
> 2. Deploy next version of application in "disabled" state with same "runtime-name"  
> ~~~
> [domain at localhost:9999 /] deploy /Applications/WebApp-2.war --disabled --name=WebApp-2.war --runtime-name=WebApp-1.war 
> ~~~
> 3. Now use replace-deployment command to access latest version of application:
> ~~~
> [domain at localhost:9999 /] /server-group=main-server-group:replace-deployment(name=WebApp-2.war,to-replace=WebApp-1.war)
> ~~~
> its working fine,laest version of application is accessable.
> 4. Now try to undeploy old version of application
> ~~~
> /server-group=main-server-group/deployment=WebApp-1.war:undeploy()
> ~~~
> After undploying older version, we are not able to access(404) latest version of application(WebApp-2.war) as well.To access it we have to redeploy it. 
> Same steps are working fine in Standalone mode.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 01:15:00 2017
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Fri, 8 Dec 2017 01:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-183) NullPointerException happens
 at ELEvaluator.parseExpressionString() due to a concurrency issue
In-Reply-To: <JIRA.12723786.1512572196000@Atlassian.JIRA>
References: <JIRA.12723786.1512572196000@Atlassian.JIRA>
	<JIRA.12723786.1512572196000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723786.1512572196000.98113.1512713700398@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Masafumi Miura updated JBEE-183:
--------------------------------
    Description: 
The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 

Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)

{code}
ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /example/index.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
    ...(snip)...
    ...
Caused by: java.lang.NullPointerException
    at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
    at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
    at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
    at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
    at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
    at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
    at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    ... 61 more
{code}



- https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277

{code}
252     public Object parseExpressionString(String pExpressionString)
253             throws ELException {
254         // See if it's an empty String
255         if (pExpressionString.length() == 0) {
256             return "";
257         }
258
259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
260             createExpressionStringMap();
261         }
262
263         // See if it's in the cache
264         Object ret =
265                 mBypassCache ?
266                         null :
267                         sCachedExpressionStrings.get(pExpressionString);
268
269         if (ret == null) {
270             // Parse the expression
271             Reader r = new StringReader(pExpressionString);
272             ELParser parser = new ELParser(r);
273             try {
274                 ret = parser.ExpressionString();
275                 if (!mBypassCache) {
276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
277                 }
278             }
279             catch (ParseException exc) {
280                 throw new ELException
281                         (formatParseException(pExpressionString,
282                                 exc));
283             }
284             catch (TokenMgrError exc) {
285                 // Note - this should never be reached, since the parser is
286                 // constructed to tokenize any input (illegal inputs get
287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
288                 // <ILLEGAL_CHARACTER>
289                 throw new ELException(exc.getMessage());
290             }
291         }
292         return ret;
293     }
{code}

- https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71

{code}
~~~
 51     /**
 52      * The singleton instance of the evaluator *
 53      */
 54     static ELEvaluator sEvaluator =
 55             new ELEvaluator
 56                     (new JSTLVariableResolver());
 :
 62     /**
 63      * Translation time validation of an attribute value.  This method
 64      * will return a null String if the attribute value is valid;
 65      * otherwise an error message.
 66      */
 67     public String validate(String pAttributeName,
 68                            String pAttributeValue) {
 69         try {
 70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
 71             sEvaluator.parseExpressionString(pAttributeValue);
 72             sEvaluator.setBypassCache(false);
 73             return null;
 74         }
 75         catch (ELException exc) {
{code}

  was:
The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 

Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)

{code}
ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /dsl/g/clsys/cl/nop-constind/CNC001.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
    ...(snip)...
    ...
Caused by: java.lang.NullPointerException
    at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
    at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
    at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
    at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
    at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
    at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
    at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
    at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
    ... 61 more
{code}



- https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277

{code}
252     public Object parseExpressionString(String pExpressionString)
253             throws ELException {
254         // See if it's an empty String
255         if (pExpressionString.length() == 0) {
256             return "";
257         }
258
259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
260             createExpressionStringMap();
261         }
262
263         // See if it's in the cache
264         Object ret =
265                 mBypassCache ?
266                         null :
267                         sCachedExpressionStrings.get(pExpressionString);
268
269         if (ret == null) {
270             // Parse the expression
271             Reader r = new StringReader(pExpressionString);
272             ELParser parser = new ELParser(r);
273             try {
274                 ret = parser.ExpressionString();
275                 if (!mBypassCache) {
276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
277                 }
278             }
279             catch (ParseException exc) {
280                 throw new ELException
281                         (formatParseException(pExpressionString,
282                                 exc));
283             }
284             catch (TokenMgrError exc) {
285                 // Note - this should never be reached, since the parser is
286                 // constructed to tokenize any input (illegal inputs get
287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
288                 // <ILLEGAL_CHARACTER>
289                 throw new ELException(exc.getMessage());
290             }
291         }
292         return ret;
293     }
{code}

- https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71

{code}
~~~
 51     /**
 52      * The singleton instance of the evaluator *
 53      */
 54     static ELEvaluator sEvaluator =
 55             new ELEvaluator
 56                     (new JSTLVariableResolver());
 :
 62     /**
 63      * Translation time validation of an attribute value.  This method
 64      * will return a null String if the attribute value is valid;
 65      * otherwise an error message.
 66      */
 67     public String validate(String pAttributeName,
 68                            String pAttributeValue) {
 69         try {
 70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
 71             sEvaluator.parseExpressionString(pAttributeValue);
 72             sEvaluator.setBypassCache(false);
 73             return null;
 74         }
 75         catch (ELException exc) {
{code}



> NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBEE-183
>                 URL: https://issues.jboss.org/browse/JBEE-183
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jstl-api
>         Environment: - JBoss EAP 7.0.8
> - jboss-jstl-api_1.2_spec-1.1.3.Final
>            Reporter: Masafumi Miura
>            Assignee: Tomas Hofman
>         Attachments: byteman-script.btm, example.zip
>
>
> The following NullPointerException happens at ELEvaluator.parseExpressionString() due to a concurrency issue. 
> Once this NPE happens, you will see same NPE every time when accessing the failed JSP. (If development="true" is configured in <jsp-config>, recompile can happen in the next access, so NPE can disappear after successful compilation in the next access.)
> {code}
> ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /example/index.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:667) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
>     ...(snip)...
>     ...
> Caused by: java.lang.NullPointerException
>     at org.apache.taglibs.standard.lang.jstl.ELEvaluator.parseExpressionString(ELEvaluator.java:276) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.jstl.Evaluator.validate(Evaluator.java:71) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.validate(ExpressionEvaluatorManager.java:131) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.ValidationUtil.validateExpression(ValidationUtil.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.el.JstlELCoreTLV.validateExpression(JstlELCoreTLV.java:26) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV$Handler.startElement(JstlCoreTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
>     at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
>     at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1653)
>     at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
>     at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
>     at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
>     at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
>     at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
>     at org.apache.taglibs.standard.tlv.JstlBaseTLV.validate(JstlBaseTLV.java:158) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.taglibs.standard.tlv.JstlCoreTLV.validate(JstlCoreTLV.java:97) [jboss-jstl-api_1.2_spec-1.1.3.Final-redhat-1.jar:1.1.3.Final-redhat-1]
>     at org.apache.jasper.compiler.TagLibraryInfoImpl.validate(TagLibraryInfoImpl.java:552) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateXmlView(Validator.java:1856) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1825) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) [jastow-2.0.0.Final-redhat-1.jar:2.0.0.Final-redhat-1]
>     ... 61 more
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/ELEvaluator.java#L275-L277
> {code}
> 252     public Object parseExpressionString(String pExpressionString)
> 253             throws ELException {
> 254         // See if it's an empty String
> 255         if (pExpressionString.length() == 0) {
> 256             return "";
> 257         }
> 258
> 259         if (!(mBypassCache) && (sCachedExpressionStrings == null)) {
> 260             createExpressionStringMap();
> 261         }
> 262
> 263         // See if it's in the cache
> 264         Object ret =
> 265                 mBypassCache ?
> 266                         null :
> 267                         sCachedExpressionStrings.get(pExpressionString);
> 268
> 269         if (ret == null) {
> 270             // Parse the expression
> 271             Reader r = new StringReader(pExpressionString);
> 272             ELParser parser = new ELParser(r);
> 273             try {
> 274                 ret = parser.ExpressionString();
> 275                 if (!mBypassCache) {
> 276                     sCachedExpressionStrings.put(pExpressionString, ret); // <- NPE occurred at here
> 277                 }
> 278             }
> 279             catch (ParseException exc) {
> 280                 throw new ELException
> 281                         (formatParseException(pExpressionString,
> 282                                 exc));
> 283             }
> 284             catch (TokenMgrError exc) {
> 285                 // Note - this should never be reached, since the parser is
> 286                 // constructed to tokenize any input (illegal inputs get
> 287                 // parsed to <BADLY_ESCAPED_STRING_LITERAL> or
> 288                 // <ILLEGAL_CHARACTER>
> 289                 throw new ELException(exc.getMessage());
> 290             }
> 291         }
> 292         return ret;
> 293     }
> {code}
> - https://github.com/jboss/jboss-jstl-api_spec/blob/jboss-jstl-api_1.2_spec-1.1.3.Final/src/main/java/org/apache/taglibs/standard/lang/jstl/Evaluator.java#L70-L71
> {code}
> ~~~
>  51     /**
>  52      * The singleton instance of the evaluator *
>  53      */
>  54     static ELEvaluator sEvaluator =
>  55             new ELEvaluator
>  56                     (new JSTLVariableResolver());
>  :
>  62     /**
>  63      * Translation time validation of an attribute value.  This method
>  64      * will return a null String if the attribute value is valid;
>  65      * otherwise an error message.
>  66      */
>  67     public String validate(String pAttributeName,
>  68                            String pAttributeValue) {
>  69         try {
>  70             sEvaluator.setBypassCache(true);   // <-- mBypassCache is set to true before invoking parseExpressionString()
>  71             sEvaluator.parseExpressionString(pAttributeValue);
>  72             sEvaluator.setBypassCache(false);
>  73             return null;
>  74         }
>  75         catch (ELException exc) {
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 02:27:00 2017
From: issues at jboss.org (Osamu Nagano (JIRA))
Date: Fri, 8 Dec 2017 02:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-186) Rotation at other than
 midnight without changing time zone
In-Reply-To: <JIRA.12724050.1512718005000@Atlassian.JIRA>
References: <JIRA.12724050.1512718005000@Atlassian.JIRA>
	<JIRA.12724050.1512718005426@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724050.1512718005000.98300.1512718020233@Atlassian.JIRA>

Osamu Nagano created LOGMGR-186:
-----------------------------------

             Summary: Rotation at other than midnight without changing time zone
                 Key: LOGMGR-186
                 URL: https://issues.jboss.org/browse/LOGMGR-186
             Project: JBoss Log Manager
          Issue Type: Enhancement
          Components: core
            Reporter: Osamu Nagano


Add ability to rotate at other than midnight without changing time zone.

Background: a global company distributes hosts around the world and all hosts configure the same time zone, UTC. In some zone, it's the peak time at midnight and the log file is divided by the rotation. They want to make the rotation time be configurable.

WebLogic has such a configuration, "Begin Rotation Time":
https://docs.oracle.com/cd/E21764_01/apirefs.1111/e13952/taskhelp/logging/RotateLogFiles.html



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 02:49:00 2017
From: issues at jboss.org (Osamu Nagano (JIRA))
Date: Fri, 8 Dec 2017 02:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-186) Rotation at other than
 midnight without changing time zone
In-Reply-To: <JIRA.12724050.1512718005000@Atlassian.JIRA>
References: <JIRA.12724050.1512718005000@Atlassian.JIRA>
	<JIRA.12724050.1512718005000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724050.1512718005000.98355.1512719340158@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGMGR-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503257#comment-13503257 ] 

Osamu Nagano edited comment on LOGMGR-186 at 12/8/17 2:48 AM:
--------------------------------------------------------------

This is personally tested and worked on EAP using a {{<custom-handler>}}. {{logging.properties}} should be edited to choose a proper constructor (using a setter doesn't work).

{code}
handler.CUSTOM.constructorProperties=fileName,append,hourOfDay
{code}

I had changed {{PeriodicRotatingFileHandler}} directly rather than subclassing it because the rotation logic is mostly in the class as a private method.


was (Author: osamu.nagano):
This is personally tested and worked on EAP using a {{<custom-handler>}}. {{logging.properties}} should be edited to choose a proper constructor.

{code}
handler.CUSTOM.properties=enabled,append,fileName,suffix,hourOfDay
{code}

I had changed {{PeriodicRotatingFileHandler}} directly rather than subclassing it because the rotation logic is mostly in the class as a private method.

> Rotation at other than midnight without changing time zone
> ----------------------------------------------------------
>
>                 Key: LOGMGR-186
>                 URL: https://issues.jboss.org/browse/LOGMGR-186
>             Project: JBoss Log Manager
>          Issue Type: Enhancement
>          Components: core
>            Reporter: Osamu Nagano
>
> Add ability to rotate at other than midnight without changing time zone.
> Background: a global company distributes hosts around the world and all hosts configure the same time zone, UTC. In some zone, it's the peak time at midnight and the log file is divided by the rotation. They want to make the rotation time be configurable.
> WebLogic has such a configuration, "Begin Rotation Time":
> https://docs.oracle.com/cd/E21764_01/apirefs.1111/e13952/taskhelp/logging/RotateLogFiles.html



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 03:40:00 2017
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Fri, 8 Dec 2017 03:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2169) IBM JDK:
 KeyStoreHelperTest.testLoadPassword fails on IBM JDK
In-Reply-To: <JIRA.12724055.1512722366000@Atlassian.JIRA>
References: <JIRA.12724055.1512722366000@Atlassian.JIRA>
	<JIRA.12724055.1512722366035@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724055.1512722366000.98525.1512722400316@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2169:
-------------------------------------

             Summary: IBM JDK: KeyStoreHelperTest.testLoadPassword fails on IBM JDK
                 Key: DROOLS-2169
                 URL: https://issues.jboss.org/browse/DROOLS-2169
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Tibor Zim?nyi


When running the test on IBM JDK, it fails with this stack [2]. A keystore that is not created by IBM JDK is used in the test, which can be a cause for this problem. See this example [1].

[1] http://www-01.ibm.com/support/docview.wss?uid=swg21692970
[1] java.lang.RuntimeException: Error initialising KeyStore: com.sun.crypto.provider.SealedObjectForKeyProtector
	at com.ibm.crypto.provider.JceKeyStore.engineLoad(Unknown Source)
	at java.security.KeyStore.load(KeyStore.java:1456)
	at org.drools.core.util.KeyStoreHelper.loadKeystore(KeyStoreHelper.java:144)
	at org.drools.core.util.KeyStoreHelper.initKeyStore(KeyStoreHelper.java:138)
	at org.drools.core.util.KeyStoreHelper.<init>(KeyStoreHelper.java:96)
	at org.drools.core.util.KeyStoreHelperTest.testLoadPassword(KeyStoreHelperTest.java:91)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Dec  8 03:48:00 2017
From: issues at jboss.org (Osamu Nagano (JIRA))
Date: Fri, 8 Dec 2017 03:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1362) NPE from
 SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnForFrequencyCheck
In-Reply-To: <JIRA.12724057.1512722878000@Atlassian.JIRA>
References: <JIRA.12724057.1512722878000@Atlassian.JIRA>
	<JIRA.12724057.1512722878087@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724057.1512722878000.98564.1512722880626@Atlassian.JIRA>

Osamu Nagano created JBJCA-1362:
-----------------------------------

             Summary: NPE from SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnForFrequencyCheck
                 Key: JBJCA-1362
                 URL: https://issues.jboss.org/browse/JBJCA-1362
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
            Reporter: Osamu Nagano


NPE happens in the ConnectionValidator thread, about once a week on EAP 7.0.7 (IronJacamar 1.3.7.Final-redhat-1).

{code}
2017-11-23 14:02:49,527 WARN  [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) IJ000602: ConnectionValidator ignored unexpected runtime exception: java.lang.NullPointerException
        at java.util.concurrent.ConcurrentLinkedDeque.checkNotNull(ConcurrentLinkedDeque.java:798)
        at java.util.concurrent.ConcurrentLinkedDeque.linkLast(ConcurrentLinkedDeque.java:386)
        at java.util.concurrent.ConcurrentLinkedDeque.addLast(ConcurrentLinkedDeque.java:903)
        at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnForFrequencyCheck(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1597)
        at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.validateConnections(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1523)
        at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator$ConnectionValidatorRunner.run(ConnectionValidator.java:277)
        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)
{code}

Configuration:
{code}
    <datasource jndi-name="java:/DB1" pool-name="DB1" statistics-enabled="true">
        <connection-url>jdbc:oracle:thin:@ServerA:1521:DB1</connection-url>
        <driver-class>oracle.jdbc.OracleDriver</driver-class>
        <connection-property name="v$session.program">
            ServerA
        </connection-property>
        <driver>oracle</driver>
        <pool>
            <min-pool-size>490</min-pool-size>
            <initial-pool-size>490</initial-pool-size>
            <max-pool-size>490</max-pool-size>
            <prefill>true</prefill>
            <allow-multiple-users>false</allow-multiple-users>
        </pool>
        <security>
            <user-name>username</user-name>
            <password>password</password>
        </security>
        <validation>
            <check-valid-connection-sql>SELECT 1 FROM DUAL</check-valid-connection-sql>
            <validate-on-match>false</validate-on-match>
            <background-validation>true</background-validation>
            <background-validation-millis>120000</background-validation-millis>
        </validation>
        <timeout>
            <blocking-timeout-millis>3000</blocking-timeout-millis>
            <allocation-retry>10</allocation-retry>
            <allocation-retry-wait-millis>60000</allocation-retry-wait-millis>
        </timeout>
        <statement>
            <prepared-statement-cache-size>10</prepared-statement-cache-size>
        </statement>
    </datasource>
{code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 05:12:00 2017
From: issues at jboss.org (Eirikur Ari Petursson (JIRA))
Date: Fri, 8 Dec 2017 05:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9603) Wildfly constantly loges out
 warning message when using picketbox to encrypt user credentials
In-Reply-To: <JIRA.12724068.1512727868000@Atlassian.JIRA>
References: <JIRA.12724068.1512727868000@Atlassian.JIRA>
	<JIRA.12724068.1512727868056@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724068.1512727868000.98827.1512727920409@Atlassian.JIRA>

Eirikur Ari Petursson created WFLY-9603:
-------------------------------------------

             Summary: Wildfly constantly loges out warning message when using picketbox to encrypt user credentials
                 Key: WFLY-9603
                 URL: https://issues.jboss.org/browse/WFLY-9603
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 11.0.0.Final
            Reporter: Eirikur Ari Petursson
            Assignee: Jason Greene
            Priority: Minor


h5. The problem
While trying out Wildfly 11 with defined security domain that uses picketbox SecureIdentityLoginModule to encrypt the user access for a jdbc connection, we noticed that Wildfly is a constantly logging out the following warning:

{code}
WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/jdbc/exampleDS
WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/jdbc/exampleDS
{code}

*Note: * the username and password is not empty e.g. the password has an encrypted string produced using picketbox.
 
The thing is that this is working e.g. we are able to connect to a database providing the user credential that is defined in the security domain and in has been working i.e. in Wildfly 9 without the warning messages.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 05:13:00 2017
From: issues at jboss.org (Eirikur Ari Petursson (JIRA))
Date: Fri, 8 Dec 2017 05:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9603) Wildfly constantly loges out
 warning message when using picketbox to encrypt user credentials
In-Reply-To: <JIRA.12724068.1512727868000@Atlassian.JIRA>
References: <JIRA.12724068.1512727868000@Atlassian.JIRA>
	<JIRA.12724068.1512727868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724068.1512727868000.98839.1512727980173@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eirikur Ari Petursson updated WFLY-9603:
----------------------------------------
    Description: 
h5. The problem
While trying out Wildfly 11 with defined security domain that uses picketbox SecureIdentityLoginModule to encrypt the user access for a jdbc connection, we noticed that Wildfly is a constantly logging out the following warning:

{code}
WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/jdbc/exampleDS
WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/jdbc/exampleDS
{code}

*Note:* the username and password is not empty e.g. the password has an encrypted string produced using picketbox.
 
The thing is that this is working e.g. we are able to connect to a database providing the user credential that is defined in the security domain and in has been working i.e. in Wildfly 9 without the warning messages.

  was:
h5. The problem
While trying out Wildfly 11 with defined security domain that uses picketbox SecureIdentityLoginModule to encrypt the user access for a jdbc connection, we noticed that Wildfly is a constantly logging out the following warning:

{code}
WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/jdbc/exampleDS
WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/jdbc/exampleDS
{code}

*Note: * the username and password is not empty e.g. the password has an encrypted string produced using picketbox.
 
The thing is that this is working e.g. we are able to connect to a database providing the user credential that is defined in the security domain and in has been working i.e. in Wildfly 9 without the warning messages.



> Wildfly constantly loges out warning message when using picketbox to encrypt user credentials
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9603
>                 URL: https://issues.jboss.org/browse/WFLY-9603
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Final
>            Reporter: Eirikur Ari Petursson
>            Assignee: Jason Greene
>            Priority: Minor
>
> h5. The problem
> While trying out Wildfly 11 with defined security domain that uses picketbox SecureIdentityLoginModule to encrypt the user access for a jdbc connection, we noticed that Wildfly is a constantly logging out the following warning:
> {code}
> WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/jdbc/exampleDS
> WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/jdbc/exampleDS
> {code}
> *Note:* the username and password is not empty e.g. the password has an encrypted string produced using picketbox.
>  
> The thing is that this is working e.g. we are able to connect to a database providing the user credential that is defined in the security domain and in has been working i.e. in Wildfly 9 without the warning messages.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 05:19:00 2017
From: issues at jboss.org (Eirikur Ari Petursson (JIRA))
Date: Fri, 8 Dec 2017 05:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9603) Wildfly constantly logs out
 warning message when using picketbox to encrypt user credentials
In-Reply-To: <JIRA.12724068.1512727868000@Atlassian.JIRA>
References: <JIRA.12724068.1512727868000@Atlassian.JIRA>
	<JIRA.12724068.1512727868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724068.1512727868000.98853.1512728340157@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eirikur Ari Petursson updated WFLY-9603:
----------------------------------------
    Summary: Wildfly constantly logs out warning message when using picketbox to encrypt user credentials  (was: Wildfly constantly loges out warning message when using picketbox to encrypt user credentials)


> Wildfly constantly logs out warning message when using picketbox to encrypt user credentials
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9603
>                 URL: https://issues.jboss.org/browse/WFLY-9603
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Final
>            Reporter: Eirikur Ari Petursson
>            Assignee: Jason Greene
>            Priority: Minor
>
> h5. The problem
> While trying out Wildfly 11 with defined security domain that uses picketbox SecureIdentityLoginModule to encrypt the user access for a jdbc connection, we noticed that Wildfly is a constantly logging out the following warning:
> {code}
> WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/jdbc/exampleDS
> WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/jdbc/exampleDS
> {code}
> *Note:* the username and password is not empty e.g. the password has an encrypted string produced using picketbox.
>  
> The thing is that this is working e.g. we are able to connect to a database providing the user credential that is defined in the security domain and in has been working i.e. in Wildfly 9 without the warning messages.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 05:22:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 8 Dec 2017 05:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9603) Wildfly constantly logs out
 warning message when using picketbox to encrypt user credentials
In-Reply-To: <JIRA.12724068.1512727868000@Atlassian.JIRA>
References: <JIRA.12724068.1512727868000@Atlassian.JIRA>
	<JIRA.12724068.1512727868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724068.1512727868000.98881.1512728520447@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-9603:
-----------------------------------
    Component/s: JCA


> Wildfly constantly logs out warning message when using picketbox to encrypt user credentials
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9603
>                 URL: https://issues.jboss.org/browse/WFLY-9603
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Eirikur Ari Petursson
>            Assignee: Jason Greene
>            Priority: Minor
>
> h5. The problem
> While trying out Wildfly 11 with defined security domain that uses picketbox SecureIdentityLoginModule to encrypt the user access for a jdbc connection, we noticed that Wildfly is a constantly logging out the following warning:
> {code}
> WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/jdbc/exampleDS
> WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/jdbc/exampleDS
> {code}
> *Note:* the username and password is not empty e.g. the password has an encrypted string produced using picketbox.
>  
> The thing is that this is working e.g. we are able to connect to a database providing the user credential that is defined in the security domain and in has been working i.e. in Wildfly 9 without the warning messages.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 05:22:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 8 Dec 2017 05:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9603) Wildfly constantly logs out
 warning message when using picketbox to encrypt user credentials
In-Reply-To: <JIRA.12724068.1512727868000@Atlassian.JIRA>
References: <JIRA.12724068.1512727868000@Atlassian.JIRA>
	<JIRA.12724068.1512727868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724068.1512727868000.98886.1512728520602@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-9603:
--------------------------------------

    Assignee: Stefano Maestri  (was: Jason Greene)


> Wildfly constantly logs out warning message when using picketbox to encrypt user credentials
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9603
>                 URL: https://issues.jboss.org/browse/WFLY-9603
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Eirikur Ari Petursson
>            Assignee: Stefano Maestri
>            Priority: Minor
>
> h5. The problem
> While trying out Wildfly 11 with defined security domain that uses picketbox SecureIdentityLoginModule to encrypt the user access for a jdbc connection, we noticed that Wildfly is a constantly logging out the following warning:
> {code}
> WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/jdbc/exampleDS
> WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/jdbc/exampleDS
> {code}
> *Note:* the username and password is not empty e.g. the password has an encrypted string produced using picketbox.
>  
> The thing is that this is working e.g. we are able to connect to a database providing the user credential that is defined in the security domain and in has been working i.e. in Wildfly 9 without the warning messages.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 05:32:00 2017
From: issues at jboss.org (Eirikur Ari Petursson (JIRA))
Date: Fri, 8 Dec 2017 05:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9603) Wildfly constantly logs out
 warning message when using picketbox to encrypt user credentials
In-Reply-To: <JIRA.12724068.1512727868000@Atlassian.JIRA>
References: <JIRA.12724068.1512727868000@Atlassian.JIRA>
	<JIRA.12724068.1512727868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724068.1512727868000.98988.1512729120878@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eirikur Ari Petursson updated WFLY-9603:
----------------------------------------
    Description: 
h5. The problem
While trying out Wildfly 11 with defined security domain that uses picketbox SecureIdentityLoginModule to encrypt the user access for a jdbc connection, we noticed that Wildfly is a constantly logging out the following warning:

{code}
WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/jdbc/exampleDS
WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/jdbc/exampleDS
{code}

*Note:* the username and password is not empty e.g. the password has an encrypted string produced using picketbox.
 
The thing is that this is working e.g. we are able to connect to a database providing the user credential that is defined in the security domain and it has been working i.e. in Wildfly 9 without the warning messages.

  was:
h5. The problem
While trying out Wildfly 11 with defined security domain that uses picketbox SecureIdentityLoginModule to encrypt the user access for a jdbc connection, we noticed that Wildfly is a constantly logging out the following warning:

{code}
WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/jdbc/exampleDS
WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/jdbc/exampleDS
{code}

*Note:* the username and password is not empty e.g. the password has an encrypted string produced using picketbox.
 
The thing is that this is working e.g. we are able to connect to a database providing the user credential that is defined in the security domain and in has been working i.e. in Wildfly 9 without the warning messages.



> Wildfly constantly logs out warning message when using picketbox to encrypt user credentials
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9603
>                 URL: https://issues.jboss.org/browse/WFLY-9603
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Eirikur Ari Petursson
>            Assignee: Stefano Maestri
>            Priority: Minor
>
> h5. The problem
> While trying out Wildfly 11 with defined security domain that uses picketbox SecureIdentityLoginModule to encrypt the user access for a jdbc connection, we noticed that Wildfly is a constantly logging out the following warning:
> {code}
> WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/jdbc/exampleDS
> WARN  [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/jdbc/exampleDS
> {code}
> *Note:* the username and password is not empty e.g. the password has an encrypted string produced using picketbox.
>  
> The thing is that this is working e.g. we are able to connect to a database providing the user credential that is defined in the security domain and it has been working i.e. in Wildfly 9 without the warning messages.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 05:42:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 8 Dec 2017 05:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1412) Reapply the fix for ELY-1380
In-Reply-To: <JIRA.12716903.1508259591000@Atlassian.JIRA>
References: <JIRA.12716903.1508259591000@Atlassian.JIRA>
	<JIRA.12716903.1508259591000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12716903.1508259591000.99046.1512729722403@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-1412.
-----------------------------------
    Fix Version/s: 1.2.0.Beta9
                       (was: 1.2.0.Beta12)
       Resolution: Done


> Reapply the fix for ELY-1380
> ----------------------------
>
>                 Key: ELY-1412
>                 URL: https://issues.jboss.org/browse/ELY-1412
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta9
>
>
> This was reverted under the following issue https://issues.jboss.org/browse/ELY-1411



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 05:42:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 8 Dec 2017 05:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1437) Elytron kerberos with ipv6
	does not work
In-Reply-To: <JIRA.12719799.1510050175000@Atlassian.JIRA>
References: <JIRA.12719799.1510050175000@Atlassian.JIRA>
	<JIRA.12719799.1510050175000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719799.1510050175000.99050.1512729722712@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-1437:
-------------------------------------

    Assignee:     (was: Darran Lofthouse)


> Elytron kerberos with ipv6 does not work
> ----------------------------------------
>
>                 Key: ELY-1437
>                 URL: https://issues.jboss.org/browse/ELY-1437
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Martin Choma
>             Fix For: 1.2.0.Beta12
>
>
> If I bind server to IPv6 address, I can't make work Elytron and Kerberos.
> {noformat}
> 11:09:55,965 TRACE [org.wildfly.security] (default task-9) Created HttpServerAuthenticationMechanism [org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1 at 12b328e7] for mechanism [SPNEGO]
> 11:09:55,965 TRACE [org.wildfly.security] (default task-9) Handling MechanismInformationCallback type='HTTP' name='SPNEGO' host-name='[fe80::eab1:fcff:fe3b:f25e]' protocol='http'
> 11:09:55,965 TRACE [org.wildfly.security] (default task-9) Using HttpScope 'SESSION' with ID 'zGaDviaIZTl6mq2Mkbs5Mx3SHhdl8y21TqQv1Xpb'
> 11:09:55,966 TRACE [org.wildfly.security] (default task-9) Handling CachedIdentityAuthorizeCallback: principal = null  authorizedIdentity = null
> 11:09:55,966 TRACE [org.wildfly.security] (default task-9) Evaluating SPNEGO request: cached GSSContext = sun.security.jgss.GSSContextImpl at 5a8c982c
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Sent HTTP authorizations: [[Negotiate oRcwFaADCgEBog4EDEFob2osIHN2ZXRlIQ==]]
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Processing incoming response to a challenge...
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Caching GSSContext sun.security.jgss.GSSContextImpl at 5a8c982c
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Caching KerberosTicket null
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Call to acceptSecContext failed.: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
> 	at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:97)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:306)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> 	at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:906)
> 	at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:630)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.lambda$evaluateRequest$2(SpnegoAuthenticationMechanism.java:215)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:215)
> 	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:748)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 05:42:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 8 Dec 2017 05:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1437) Elytron kerberos with ipv6
	does not work
In-Reply-To: <JIRA.12719799.1510050175000@Atlassian.JIRA>
References: <JIRA.12719799.1510050175000@Atlassian.JIRA>
	<JIRA.12719799.1510050175000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719799.1510050175000.99054.1512729722794@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1437:
----------------------------------
    Fix Version/s: 1.2.0.Beta12


> Elytron kerberos with ipv6 does not work
> ----------------------------------------
>
>                 Key: ELY-1437
>                 URL: https://issues.jboss.org/browse/ELY-1437
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Martin Choma
>             Fix For: 1.2.0.Beta12
>
>
> If I bind server to IPv6 address, I can't make work Elytron and Kerberos.
> {noformat}
> 11:09:55,965 TRACE [org.wildfly.security] (default task-9) Created HttpServerAuthenticationMechanism [org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1 at 12b328e7] for mechanism [SPNEGO]
> 11:09:55,965 TRACE [org.wildfly.security] (default task-9) Handling MechanismInformationCallback type='HTTP' name='SPNEGO' host-name='[fe80::eab1:fcff:fe3b:f25e]' protocol='http'
> 11:09:55,965 TRACE [org.wildfly.security] (default task-9) Using HttpScope 'SESSION' with ID 'zGaDviaIZTl6mq2Mkbs5Mx3SHhdl8y21TqQv1Xpb'
> 11:09:55,966 TRACE [org.wildfly.security] (default task-9) Handling CachedIdentityAuthorizeCallback: principal = null  authorizedIdentity = null
> 11:09:55,966 TRACE [org.wildfly.security] (default task-9) Evaluating SPNEGO request: cached GSSContext = sun.security.jgss.GSSContextImpl at 5a8c982c
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Sent HTTP authorizations: [[Negotiate oRcwFaADCgEBog4EDEFob2osIHN2ZXRlIQ==]]
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Processing incoming response to a challenge...
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Caching GSSContext sun.security.jgss.GSSContextImpl at 5a8c982c
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Caching KerberosTicket null
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Call to acceptSecContext failed.: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
> 	at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:97)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:306)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> 	at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:906)
> 	at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:630)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.lambda$evaluateRequest$2(SpnegoAuthenticationMechanism.java:215)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:215)
> 	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:748)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 05:43:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 8 Dec 2017 05:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1437) Elytron kerberos with ipv6
	does not work
In-Reply-To: <JIRA.12719799.1510050175000@Atlassian.JIRA>
References: <JIRA.12719799.1510050175000@Atlassian.JIRA>
	<JIRA.12719799.1510050175000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719799.1510050175000.99061.1512729780400@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1437:
----------------------------------
    Component/s: HTTP


> Elytron kerberos with ipv6 does not work
> ----------------------------------------
>
>                 Key: ELY-1437
>                 URL: https://issues.jboss.org/browse/ELY-1437
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Martin Choma
>             Fix For: 1.2.0.Beta12
>
>
> If I bind server to IPv6 address, I can't make work Elytron and Kerberos.
> {noformat}
> 11:09:55,965 TRACE [org.wildfly.security] (default task-9) Created HttpServerAuthenticationMechanism [org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1 at 12b328e7] for mechanism [SPNEGO]
> 11:09:55,965 TRACE [org.wildfly.security] (default task-9) Handling MechanismInformationCallback type='HTTP' name='SPNEGO' host-name='[fe80::eab1:fcff:fe3b:f25e]' protocol='http'
> 11:09:55,965 TRACE [org.wildfly.security] (default task-9) Using HttpScope 'SESSION' with ID 'zGaDviaIZTl6mq2Mkbs5Mx3SHhdl8y21TqQv1Xpb'
> 11:09:55,966 TRACE [org.wildfly.security] (default task-9) Handling CachedIdentityAuthorizeCallback: principal = null  authorizedIdentity = null
> 11:09:55,966 TRACE [org.wildfly.security] (default task-9) Evaluating SPNEGO request: cached GSSContext = sun.security.jgss.GSSContextImpl at 5a8c982c
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Sent HTTP authorizations: [[Negotiate oRcwFaADCgEBog4EDEFob2osIHN2ZXRlIQ==]]
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Processing incoming response to a challenge...
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Caching GSSContext sun.security.jgss.GSSContextImpl at 5a8c982c
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Caching KerberosTicket null
> 11:09:55,967 TRACE [org.wildfly.security] (default task-9) Call to acceptSecContext failed.: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
> 	at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:97)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:306)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> 	at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:906)
> 	at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:630)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
> 	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.lambda$evaluateRequest$2(SpnegoAuthenticationMechanism.java:215)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:215)
> 	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:748)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 07:02:00 2017
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Fri, 8 Dec 2017 07:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9601) NullPointerException in build
 during checkstyle
In-Reply-To: <JIRA.12723975.1512660771000@Atlassian.JIRA>
References: <JIRA.12723975.1512660771000@Atlassian.JIRA>
	<JIRA.12723975.1512660771000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723975.1512660771000.99461.1512734520448@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Romain Pelisse updated WFLY-9601:
---------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-checkstyle-config/pull/10, https://github.com/wildfly/wildfly/pull/10698  (was: https://github.com/wildfly/wildfly/pull/10696)


> NullPointerException in build during checkstyle
> -----------------------------------------------
>
>                 Key: WFLY-9601
>                 URL: https://issues.jboss.org/browse/WFLY-9601
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>         Environment: Customized :P
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Critical
>
> {code}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle (check-style) on project wildfly-naming: Execution check-style of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle failed. NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle (check-style) on project wildfly-naming: Execution check-style of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle failed.
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> 	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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> 	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.apache.maven.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:39)
> 	at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:122)
> 	at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:50)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution check-style of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle failed.
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> 	... 27 more
> Caused by: java.lang.NullPointerException
> 	at com.puppycrawl.tools.checkstyle.checks.SuppressWarningsHolder.isSuppressed(SuppressWarningsHolder.java:200)
> 	at com.puppycrawl.tools.checkstyle.filters.SuppressWarningsFilter.accept(SuppressWarningsFilter.java:38)
> 	at com.puppycrawl.tools.checkstyle.api.FilterSet.accept(FilterSet.java:88)
> 	at com.puppycrawl.tools.checkstyle.Checker.fireErrors(Checker.java:358)
> 	at com.puppycrawl.tools.checkstyle.Checker.process(Checker.java:276)
> 	at org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:252)
> 	at org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:473)
> 	at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:154)
> 	at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
> 	at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:143)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> 	... 28 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 07:13:00 2017
From: issues at jboss.org (Martin Mazanek (JIRA))
Date: Fri, 8 Dec 2017 07:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1353)
 AuthenticationConfiguration#kerberosSecurityFactory is redundant
In-Reply-To: <JIRA.12709816.1504291238000@Atlassian.JIRA>
References: <JIRA.12709816.1504291238000@Atlassian.JIRA>
	<JIRA.12709816.1504291238000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709816.1504291238000.99567.1512735180536@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Mazanek reassigned ELY-1353:
-----------------------------------

    Assignee: Martin Mazanek


> AuthenticationConfiguration#kerberosSecurityFactory is redundant
> ----------------------------------------------------------------
>
>                 Key: ELY-1353
>                 URL: https://issues.jboss.org/browse/ELY-1353
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Assignee: Martin Mazanek
>
> There's no point to having a special/separate kerberosSecurityFactory on AuthenticationConfiguration.  The callback handling code path for this would work exactly the same if the Kerberos credential were instead stored on the regular CredentialSource in the configuration.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 07:22:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 8 Dec 2017 07:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-728) The map backing
 SimpleMapBackedSecurityRealm should be an identity map not a password map.
In-Reply-To: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.99625.1512735720455@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-728:
------------------------------

    Assignee: Jan Kalina


> The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map.
> ------------------------------------------------------------------------------------------
>
>                 Key: ELY-728
>                 URL: https://issues.jboss.org/browse/ELY-728
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>
> This realm is useful in cases where we need an identity to exist where the mechanism has performed validation without requiring access to credentials.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 08:03:00 2017
From: issues at jboss.org (Martyn Taylor (JIRA))
Date: Fri, 8 Dec 2017 08:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9590)
 auto-[create|delete]-jms-queues are not supported in Artemis 2.4
In-Reply-To: <JIRA.12723095.1512137513000@Atlassian.JIRA>
References: <JIRA.12723095.1512137513000@Atlassian.JIRA>
	<JIRA.12723095.1512137513000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723095.1512137513000.99895.1512738180209@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503411#comment-13503411 ] 

Martyn Taylor commented on WFLY-9590:
-------------------------------------

Jeff.  This feature was removed between Artemis 1.x and Artemis 2.x versions.  It was part of a bigger change that required us to break compatability and hence do the major version bump.

There is now no differentiation between "core" queues and "jms" queues.  There are several other options that can be used to split up your address space and offer various configuraiton options, such as using an address setting that matches "jms.".  It should also be noted that as part of this change, the jms. prefixing was also removed.  Something similar can be done using prefixing.  See: https://activemq.apache.org/artemis/docs/2.3.0/address-model.html

I can work with you to come up with a solution to this.

> auto-[create|delete]-jms-queues are not supported in Artemis 2.4
> ----------------------------------------------------------------
>
>                 Key: WFLY-9590
>                 URL: https://issues.jboss.org/browse/WFLY-9590
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> For more information about origin of this issue see JBEAP-13856.
> Auto-create-jms-queues and auto-delete-jms-queues enable or disable automatic creation or deletion of JMS queues when they are requested or when they are not used anymore.
> In EAP 7.1 the features are disabled by default and they are Technical previews.
> In EAP 7.2 the features cannot be disabled via mentioned management attributes and thus they are always enabled. The ?cannot be? in previous sentence means that the configuration has no effect.
> *Customer impact:* Behavior of messaging broker was changed in case of automatic creation and deletion JMS destinations.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Dec  8 08:06:00 2017
From: issues at jboss.org (Martin Mazanek (JIRA))
Date: Fri, 8 Dec 2017 08:06: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.99900.1512738360176@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503091#comment-13503091 ] 

Martin Mazanek edited comment on ELY-839 at 12/8/17 8:05 AM:
-------------------------------------------------------------

I think this can be closed, as modifying AuthenticationConfiguration is now done by private mutating constructors and SetCredentialsConfiguration no longer exists.


was (Author: mmazanek):
I think this can be closed

> 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
>
> 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  Fri Dec  8 08:12:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 8 Dec 2017 08:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2241) Bundler using direct memory
	as buffer
In-Reply-To: <JIRA.12724097.1512738712000@Atlassian.JIRA>
References: <JIRA.12724097.1512738712000@Atlassian.JIRA>
	<JIRA.12724097.1512738712524@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724097.1512738712000.99916.1512738720109@Atlassian.JIRA>

Bela Ban created JGRP-2241:
------------------------------

             Summary: 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.10


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.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 08:22:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 8 Dec 2017 08:22: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.99954.1512739320500@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2241:
---------------------------
    Description: 
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.


  was:
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.



> 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.10
>
>
> 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  Fri Dec  8 08:31:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 8 Dec 2017 08:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2240) Log a warning if no binding
 port in TCP is provided
In-Reply-To: <JIRA.12723889.1512639117000@Atlassian.JIRA>
References: <JIRA.12723889.1512639117000@Atlassian.JIRA>
	<JIRA.12723889.1512639117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723889.1512639117000.99987.1512739860308@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-2240.
--------------------------
    Resolution: Rejected


I checked and this sanity check is already in the code (but I forgot):

{noformat}
java.lang.IllegalArgumentException: bind_port cannot be set to 0, as no dynamic discovery protocol (e.g. MPING or TCPGOSSIP) has been detected.
	at org.jgroups.protocols.BasicTCP.init(BasicTCP.java:87)
	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:837)
	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:476)
	at org.jgroups.JChannel.init(JChannel.java:992)
	at org.jgroups.JChannel.<init>(JChannel.java:148)
	at org.jgroups.JChannel.<init>(JChannel.java:130)
	at org.jgroups.demos.Draw.<init>(Draw.java:57)
	at org.jgroups.demos.Draw.main(Draw.java:156)
{noformat}

> Log a warning if no binding port in TCP is provided
> ---------------------------------------------------
>
>                 Key: JGRP-2240
>                 URL: https://issues.jboss.org/browse/JGRP-2240
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 4.0.9
>            Reporter: andrea tarocchi
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0.10
>
>
> If a bind port is not defined and you don't bind (for some reason) to the default one, log a warning.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 08:52:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 8 Dec 2017 08:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-728) The map backing
 SimpleMapBackedSecurityRealm should be an identity map not a password map.
In-Reply-To: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.100068.1512741120542@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-728:
---------------------------
    Affects Version/s: 1.2.0.Beta10


> The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map.
> ------------------------------------------------------------------------------------------
>
>                 Key: ELY-728
>                 URL: https://issues.jboss.org/browse/ELY-728
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>
> This realm is useful in cases where we need an identity to exist where the mechanism has performed validation without requiring access to credentials.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 09:36:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 8 Dec 2017 09:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.100291.1512743761090@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-609:
------------------------------

    Assignee: Jan Kalina


> Unguarded read in ElytronPolicyConfiguration
> --------------------------------------------
>
>                 Key: ELY-609
>                 URL: https://issues.jboss.org/browse/ELY-609
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta7
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>              Labels: static_analysis
>             Fix For: 1.2.0.Beta12
>
>
> Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 10:00:00 2017
From: issues at jboss.org (Martin Mazanek (JIRA))
Date: Fri, 8 Dec 2017 10:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.100370.1512745200446@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Mazanek reassigned ELY-849:
----------------------------------

    Assignee: Martin Mazanek


> Rename setMechanismProperties to setSaslMechanismProperties
> -----------------------------------------------------------
>
>                 Key: ELY-849
>                 URL: https://issues.jboss.org/browse/ELY-849
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Assignee: Martin Mazanek
>             Fix For: 1.2.0.Beta12
>
>
> If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties.
> We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 10:16:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 8 Dec 2017 10:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.100502.1512746160149@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503497#comment-13503497 ] 

Jan Kalina commented on ELY-609:
--------------------------------

Not sure how do you mean "more than one lock", as all in ElytronPolicyConfiguration is synchronized against "this", but the problem I see is, even when I add synchonized block around getters, the obtained Permissions object will not be immutable - user will be able to modify Permissions collection without any sychronization...

> Unguarded read in ElytronPolicyConfiguration
> --------------------------------------------
>
>                 Key: ELY-609
>                 URL: https://issues.jboss.org/browse/ELY-609
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta7
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>              Labels: static_analysis
>             Fix For: 1.2.0.Beta12
>
>
> Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 10:19:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 8 Dec 2017 10:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.100540.1512746340278@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503497#comment-13503497 ] 

Jan Kalina edited comment on ELY-609 at 12/8/17 10:18 AM:
----------------------------------------------------------

Not sure how do you mean "more than one lock", as all in ElytronPolicyConfiguration is synchronized against "this", -but the problem I see is, even when I add synchonized block around getters, the obtained Permissions object will not be immutable - user will be able to modify Permissions collection without any sychronization...-
(edit, just looking, the Permissions object is synchonized)


was (Author: honza889):
Not sure how do you mean "more than one lock", as all in ElytronPolicyConfiguration is synchronized against "this", but the problem I see is, even when I add synchonized block around getters, the obtained Permissions object will not be immutable - user will be able to modify Permissions collection without any sychronization...

> Unguarded read in ElytronPolicyConfiguration
> --------------------------------------------
>
>                 Key: ELY-609
>                 URL: https://issues.jboss.org/browse/ELY-609
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta7
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>              Labels: static_analysis
>             Fix For: 1.2.0.Beta12
>
>
> Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 11:24:01 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 8 Dec 2017 11:24:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2170) Unhelful error message:
 "Unknown property" should not only mention the name of the property,
 but also the class on which it is expecting it (and the DRL line causing it)
In-Reply-To: <JIRA.12724147.1512750214000@Atlassian.JIRA>
References: <JIRA.12724147.1512750214000@Atlassian.JIRA>
	<JIRA.12724147.1512750214755@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724147.1512750214000.100939.1512750241966@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-2170:
----------------------------------------

             Summary: Unhelful error message: "Unknown property" should not only mention the name of the property, but also the class on which it is expecting it (and the DRL line causing it)
                 Key: DROOLS-2170
                 URL: https://issues.jboss.org/browse/DROOLS-2170
             Project: Drools
          Issue Type: Enhancement
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Geoffrey De Smet
            Assignee: Mario Fusco


I have no idea which class file it's expecting the room property on in this error message.
I 'll need to look for a needle in a haystack:

{code}
Caused by: java.lang.RuntimeException: Unknown property: room
	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at javax.swing.SwingWorker.run(SwingWorker.java:334)
	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)

{code}




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 11:27:00 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 8 Dec 2017 11:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2170) Unhelful error message:
 "Unknown property" should not only mention the name of the property,
 but also the class on which it is expecting it (and the DRL line causing it)
In-Reply-To: <JIRA.12724147.1512750215000@Atlassian.JIRA>
References: <JIRA.12724147.1512750215000@Atlassian.JIRA>
	<JIRA.12724147.1512750215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724147.1512750215000.100976.1512750420090@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503551#comment-13503551 ] 

Geoffrey De Smet commented on DROOLS-2170:
------------------------------------------

Separate issue:
I am especially a bit worried here because this happens when "typeDeclaration.isPropertyReactive()" == true, but optaplanner explicitely disables property reactive (for good reasons).

> Unhelful error message: "Unknown property" should not only mention the name of the property, but also the class on which it is expecting it (and the DRL line causing it)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2170
>                 URL: https://issues.jboss.org/browse/DROOLS-2170
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>
> I have no idea which class file it's expecting the room property on in this error message.
> I 'll need to look for a needle in a haystack:
> {code}
> Caused by: java.lang.RuntimeException: Unknown property: room
> 	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
> 	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
> 	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
> 	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
> 	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
> 	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
> 	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
> 	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
> 	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
> 	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
> 	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at javax.swing.SwingWorker.run(SwingWorker.java:334)
> 	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)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 11:31:00 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 8 Dec 2017 11:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2170) Unhelful error message:
 "Unknown property" should not only mention the name of the property,
 but also the class on which it is expecting it (and the DRL line causing it)
In-Reply-To: <JIRA.12724147.1512750215000@Atlassian.JIRA>
References: <JIRA.12724147.1512750215000@Atlassian.JIRA>
	<JIRA.12724147.1512750215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724147.1512750215000.101021.1512750660371@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-2170:
-------------------------------------
    Description: 
I have no idea which class file it's expecting the room property on in this error message.
I 'll need to look for a needle in a haystack:

{code}
Caused by: java.lang.RuntimeException: Unknown property: room
	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at javax.swing.SwingWorker.run(SwingWorker.java:334)
	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)

{code}

Reproduce recipe: 
- take meeting scheduling example in optaplanner-examplse
- remove getters and setters for room in MeetingAssignment.java
- remove all rules in the drl (to avoid it crashing on something else sooner), especially those that involve the room.
- the error occurs when DroolsScoreDirector.update("room") is called


  was:
I have no idea which class file it's expecting the room property on in this error message.
I 'll need to look for a needle in a haystack:

{code}
Caused by: java.lang.RuntimeException: Unknown property: room
	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at javax.swing.SwingWorker.run(SwingWorker.java:334)
	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)

{code}




> Unhelful error message: "Unknown property" should not only mention the name of the property, but also the class on which it is expecting it (and the DRL line causing it)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2170
>                 URL: https://issues.jboss.org/browse/DROOLS-2170
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>
> I have no idea which class file it's expecting the room property on in this error message.
> I 'll need to look for a needle in a haystack:
> {code}
> Caused by: java.lang.RuntimeException: Unknown property: room
> 	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
> 	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
> 	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
> 	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
> 	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
> 	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
> 	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
> 	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
> 	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
> 	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
> 	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at javax.swing.SwingWorker.run(SwingWorker.java:334)
> 	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)
> {code}
> Reproduce recipe: 
> - take meeting scheduling example in optaplanner-examplse
> - remove getters and setters for room in MeetingAssignment.java
> - remove all rules in the drl (to avoid it crashing on something else sooner), especially those that involve the room.
> - the error occurs when DroolsScoreDirector.update("room") is called



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 11:31:00 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 8 Dec 2017 11:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2170) Unhelful error message:
 "Unknown property" should not only mention the name of the property,
 but also the class on which it is expecting it (and the DRL line causing it)
In-Reply-To: <JIRA.12724147.1512750215000@Atlassian.JIRA>
References: <JIRA.12724147.1512750215000@Atlassian.JIRA>
	<JIRA.12724147.1512750215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724147.1512750215000.101024.1512750660425@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-2170:
-------------------------------------
    Description: 
I have no idea which class file it's expecting the room property on in this error message.
I 'll need to look for a needle in a haystack:

{code}
Caused by: java.lang.RuntimeException: Unknown property: room
	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at javax.swing.SwingWorker.run(SwingWorker.java:334)
	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)

{code}

Reproduce recipe: 
- take meeting scheduling example in optaplanner-examplse
- remove getters and setters for room in MeetingAssignment.java
- remove all rules in the drl (to avoid it crashing on something else sooner), especially those that involve the room.
- the error occurs when DroolsScoreDirector.update(meetingAssignment, "room") is called


  was:
I have no idea which class file it's expecting the room property on in this error message.
I 'll need to look for a needle in a haystack:

{code}
Caused by: java.lang.RuntimeException: Unknown property: room
	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at javax.swing.SwingWorker.run(SwingWorker.java:334)
	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)

{code}

Reproduce recipe: 
- take meeting scheduling example in optaplanner-examplse
- remove getters and setters for room in MeetingAssignment.java
- remove all rules in the drl (to avoid it crashing on something else sooner), especially those that involve the room.
- the error occurs when DroolsScoreDirector.update("room") is called




> Unhelful error message: "Unknown property" should not only mention the name of the property, but also the class on which it is expecting it (and the DRL line causing it)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2170
>                 URL: https://issues.jboss.org/browse/DROOLS-2170
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>
> I have no idea which class file it's expecting the room property on in this error message.
> I 'll need to look for a needle in a haystack:
> {code}
> Caused by: java.lang.RuntimeException: Unknown property: room
> 	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
> 	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
> 	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
> 	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
> 	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
> 	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
> 	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
> 	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
> 	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
> 	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
> 	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at javax.swing.SwingWorker.run(SwingWorker.java:334)
> 	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)
> {code}
> Reproduce recipe: 
> - take meeting scheduling example in optaplanner-examplse
> - remove getters and setters for room in MeetingAssignment.java
> - remove all rules in the drl (to avoid it crashing on something else sooner), especially those that involve the room.
> - the error occurs when DroolsScoreDirector.update(meetingAssignment, "room") is called



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 11:31:00 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 8 Dec 2017 11:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2170) Unhelful error message:
 "Unknown property" should not only mention the name of the property,
 but also the class on which it is expecting it (and the DRL line causing it)
In-Reply-To: <JIRA.12724147.1512750215000@Atlassian.JIRA>
References: <JIRA.12724147.1512750215000@Atlassian.JIRA>
	<JIRA.12724147.1512750215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724147.1512750215000.101027.1512750660561@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-2170:
-------------------------------------
    Description: 
I had no idea which class file it's expecting the room property on in this error message.
I 'll needed to look for a needle in a haystack:

{code}
Caused by: java.lang.RuntimeException: Unknown property: room
	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at javax.swing.SwingWorker.run(SwingWorker.java:334)
	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)

{code}

Reproduce recipe: 
- take meeting scheduling example in optaplanner-examplse
- remove getters and setters for room in MeetingAssignment.java
- remove all rules in the drl (to avoid it crashing on something else sooner), especially those that involve the room.
- the error occurs when DroolsScoreDirector.update(meetingAssignment, "room") is called


  was:
I have no idea which class file it's expecting the room property on in this error message.
I 'll need to look for a needle in a haystack:

{code}
Caused by: java.lang.RuntimeException: Unknown property: room
	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at javax.swing.SwingWorker.run(SwingWorker.java:334)
	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)

{code}

Reproduce recipe: 
- take meeting scheduling example in optaplanner-examplse
- remove getters and setters for room in MeetingAssignment.java
- remove all rules in the drl (to avoid it crashing on something else sooner), especially those that involve the room.
- the error occurs when DroolsScoreDirector.update(meetingAssignment, "room") is called




> Unhelful error message: "Unknown property" should not only mention the name of the property, but also the class on which it is expecting it (and the DRL line causing it)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2170
>                 URL: https://issues.jboss.org/browse/DROOLS-2170
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>
> I had no idea which class file it's expecting the room property on in this error message.
> I 'll needed to look for a needle in a haystack:
> {code}
> Caused by: java.lang.RuntimeException: Unknown property: room
> 	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
> 	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
> 	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
> 	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
> 	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
> 	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
> 	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
> 	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
> 	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
> 	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
> 	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at javax.swing.SwingWorker.run(SwingWorker.java:334)
> 	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)
> {code}
> Reproduce recipe: 
> - take meeting scheduling example in optaplanner-examplse
> - remove getters and setters for room in MeetingAssignment.java
> - remove all rules in the drl (to avoid it crashing on something else sooner), especially those that involve the room.
> - the error occurs when DroolsScoreDirector.update(meetingAssignment, "room") is called



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 12:03:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 8 Dec 2017 12:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2132) [DMN Editor] Boxed
 Expressions: FunctionDefinition editor
In-Reply-To: <JIRA.12720928.1510654087000@Atlassian.JIRA>
References: <JIRA.12720928.1510654087000@Atlassian.JIRA>
	<JIRA.12720928.1510654087000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720928.1510654087000.101098.1512752580289@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis resolved DROOLS-2132.
------------------------------------
    Resolution: Done


> [DMN Editor] Boxed Expressions: FunctionDefinition editor
> ---------------------------------------------------------
>
>                 Key: DROOLS-2132
>                 URL: https://issues.jboss.org/browse/DROOLS-2132
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 12:22:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 8 Dec 2017 12:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1456) Two same SQL queries seen
 during one authentication attempt
In-Reply-To: <JIRA.12722891.1512035276000@Atlassian.JIRA>
References: <JIRA.12722891.1512035276000@Atlassian.JIRA>
	<JIRA.12722891.1512035276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722891.1512035276000.101145.1512753720268@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503574#comment-13503574 ] 

Darran Lofthouse commented on ELY-1456:
---------------------------------------

There are two parts to this really: -
# The JDBC SecurityRealm is older than the IdentityCredentials and CachingSecurityRealm, it does already load the credentials in one go but stores them in a list, it can instead add them all to IdentityCredentials that can then take over the supports / get / verify calls.
# Although there is a single principal query it is executed once per credential type supported and once for the attributes - instead it should be executed once and the ResultSet re-used for each item being read from the results.

> Two same SQL queries seen during one authentication attempt 
> ------------------------------------------------------------
>
>                 Key: ELY-1456
>                 URL: https://issues.jboss.org/browse/ELY-1456
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta11
>
>
> Two same sql queries are performed on authentication attempt using jdbc-realm.
> {noformat}
> 2017-11-29T15:53:32.399596Z   338 Query select password from user where email = 'alberto at myapp.com'
> 2017-11-29T15:53:32.400879Z   338 Query select role, 'Roles' from user_role_auth where email = 'alberto at myapp.com'
> 2017-11-29T15:53:32.402531Z   338 Query select password from user where email = 'alberto at myapp.com'
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 12:43:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 8 Dec 2017 12:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.101177.1512754980202@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503578#comment-13503578 ] 

Jan Kalina commented on ELY-609:
--------------------------------

I has go through it and it looks no synchronization is actually needed here - synchronized blocks need to protect state changes only, so adding *volatile* to create atomic reference will be sufficient.

> Unguarded read in ElytronPolicyConfiguration
> --------------------------------------------
>
>                 Key: ELY-609
>                 URL: https://issues.jboss.org/browse/ELY-609
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta7
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>              Labels: static_analysis
>             Fix For: 1.2.0.Beta12
>
>
> Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 13:05:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 8 Dec 2017 13:05: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.101296.1512756300184@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503583#comment-13503583 ] 

Jan Kalina commented on ELY-286:
--------------------------------

Part of RFC 7616 (alternative hashing algorithms handling) is already implemented as part of ELY-1369.

> 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.Beta12
>
>
> 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  Fri Dec  8 14:31:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 8 Dec 2017 14:31:00 -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.101446.1512761460442@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1455:
----------------------------------
    Summary:  DB query seen for each request using programatic authentication  (was:  DB query seen for each request using FORM mechanism.)


>  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.Beta11
>
>         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  Fri Dec  8 14:34:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 8 Dec 2017 14:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1456) JDBC SecurityRealm executing
 single principal query multiple times.
In-Reply-To: <JIRA.12722891.1512035276000@Atlassian.JIRA>
References: <JIRA.12722891.1512035276000@Atlassian.JIRA>
	<JIRA.12722891.1512035276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722891.1512035276000.101456.1512761640199@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1456:
----------------------------------
    Summary: JDBC SecurityRealm executing single principal query multiple times.  (was: Two same SQL queries seen during one authentication attempt )


> JDBC SecurityRealm executing single principal query multiple times.
> -------------------------------------------------------------------
>
>                 Key: ELY-1456
>                 URL: https://issues.jboss.org/browse/ELY-1456
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta11
>
>
> Two same sql queries are performed on authentication attempt using jdbc-realm.
> {noformat}
> 2017-11-29T15:53:32.399596Z   338 Query select password from user where email = 'alberto at myapp.com'
> 2017-11-29T15:53:32.400879Z   338 Query select role, 'Roles' from user_role_auth where email = 'alberto at myapp.com'
> 2017-11-29T15:53:32.402531Z   338 Query select password from user where email = 'alberto at myapp.com'
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec  8 14:44:00 2017
From: issues at jboss.org (Yun Lin (JIRA))
Date: Fri, 8 Dec 2017 14:44: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.1512762239393@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724167.1512762239000.101464.1512762240161@Atlassian.JIRA>

Yun Lin created DROOLS-2171:
-------------------------------

             Summary: NullPointerException in drools core 
                 Key: DROOLS-2171
                 URL: https://issues.jboss.org/browse/DROOLS-2171
             Project: Drools
          Issue Type: Feature Request
            Reporter: Yun Lin
            Assignee: Edson Tirelli
            Priority: Critical


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  Fri Dec  8 14:46:00 2017
From: issues at jboss.org (Yun Lin (JIRA))
Date: Fri, 8 Dec 2017 14:46: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.101471.1512762360294@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yun Lin updated DROOLS-2171:
----------------------------
    Issue Type: Bug  (was: Feature Request)


> NullPointerException in drools core 
> ------------------------------------
>
>                 Key: DROOLS-2171
>                 URL: https://issues.jboss.org/browse/DROOLS-2171
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Yun Lin
>            Assignee: Edson Tirelli
>            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  Fri Dec  8 16:01:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 8 Dec 2017 16:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2163) [DMN Editor] Context table
 doesn't show entry type label if table is scrolled
In-Reply-To: <JIRA.12723671.1512545036000@Atlassian.JIRA>
References: <JIRA.12723671.1512545036000@Atlassian.JIRA>
	<JIRA.12723671.1512545036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723671.1512545036000.101627.1512766860396@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2163:
-----------------------------------
    Sprint: 2017 Week 49-50


> [DMN Editor] Context table doesn't show entry type label if table is scrolled
> -----------------------------------------------------------------------------
>
>                 Key: DROOLS-2163
>                 URL: https://issues.jboss.org/browse/DROOLS-2163
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>
> Context table offers 5 types of entries while each entry has label of its own type (Literal Expression, Function Relation etc.) However this label is not shown if the user scroll the table.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Dec  9 11:28:00 2017
From: issues at jboss.org (Trond Tobiassen (JIRA))
Date: Sat, 9 Dec 2017 11:28: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.1512836827151@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724194.1512836827000.101893.1512836880108@Atlassian.JIRA>

Trond Tobiassen created WFLY-9604:
-------------------------------------

             Summary: 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 Tobiassen
             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  Sat Dec  9 11:57:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sat, 9 Dec 2017 11:57: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.101898.1512838620275@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-2171:
-------------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> 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  Sun Dec 10 14:01:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 10 Dec 2017 14:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3452) If the legacy SecurityRealm
 references a non-existant alias in the CredentialStore a null password is
 assumed.
In-Reply-To: <JIRA.12724200.1512932454000@Atlassian.JIRA>
References: <JIRA.12724200.1512932454000@Atlassian.JIRA>
	<JIRA.12724200.1512932454652@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724200.1512932454000.101933.1512932460451@Atlassian.JIRA>

Darran Lofthouse created WFCORE-3452:
----------------------------------------

             Summary: If the legacy SecurityRealm references a non-existant alias in the CredentialStore a null password is assumed.
                 Key: WFCORE-3452
                 URL: https://issues.jboss.org/browse/WFCORE-3452
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management, Security
    Affects Versions: 4.0.0.Alpha4, 3.0.9.Final
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse


We may need to double check CredentialStore references in general as a reference to non-existant alias probably should cause service start up to fail.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Dec 10 14:02:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 10 Dec 2017 14:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3452) If the legacy SecurityRealm
 references a non-existant alias in the CredentialStore a null password is
 assumed.
In-Reply-To: <JIRA.12724200.1512932455000@Atlassian.JIRA>
References: <JIRA.12724200.1512932455000@Atlassian.JIRA>
	<JIRA.12724200.1512932455000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724200.1512932455000.101944.1512932520480@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-3452:
-------------------------------------
    Description: 
We may need to double check CredentialStore references in general as a reference to non-existant alias probably should cause service start up to fail.

{noformat}
18:41:45,072 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.SimpleSSL.key-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.SimpleSSL.key-manager: WFLYDM0018: Unable to start service
	at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.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 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: java.security.UnrecoverableKeyException: Password must not be null
	at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:132)
	at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:56)
	at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
	at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:70)
	at java.security.KeyStore.getKey(KeyStore.java:1023)
	at sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:133)
	at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
	at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
	at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:140)
	at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:89)
	... 5 more
{noformat}

  was:We may need to double check CredentialStore references in general as a reference to non-existant alias probably should cause service start up to fail.



> If the legacy SecurityRealm references a non-existant alias in the CredentialStore a null password is assumed.
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3452
>                 URL: https://issues.jboss.org/browse/WFCORE-3452
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 3.0.9.Final, 4.0.0.Alpha4
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>
> We may need to double check CredentialStore references in general as a reference to non-existant alias probably should cause service start up to fail.
> {noformat}
> 18:41:45,072 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.SimpleSSL.key-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.SimpleSSL.key-manager: WFLYDM0018: Unable to start service
> 	at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.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 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: java.security.UnrecoverableKeyException: Password must not be null
> 	at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:132)
> 	at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:56)
> 	at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
> 	at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:70)
> 	at java.security.KeyStore.getKey(KeyStore.java:1023)
> 	at sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:133)
> 	at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
> 	at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
> 	at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:140)
> 	at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:89)
> 	... 5 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Dec 10 16:06:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 10 Dec 2017 16:06:00 -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.101983.1512939960869@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3073:
-------------------------------------
    Summary: Handle Shutdown via TERM gracefully  (was: Handle TERM gracefully)


> 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.Alpha5
>
>
> 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  Sun Dec 10 19:41:00 2017
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Sun, 10 Dec 2017 19:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.102023.1512952860233@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503664#comment-13503664 ] 

Tomasz Adamski commented on WFLY-9585:
--------------------------------------

I have created reproducer for this issue, but it seems to work correctly - can paste the fragment of the bean in which you use InitialContext to lookup the DataSource?

> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Dec 10 19:44:00 2017
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Sun, 10 Dec 2017 19:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6885) Exception swallowed by
 CmtTxInterceptor if transaction has been cancelled by reaper
In-Reply-To: <JIRA.12640957.1469657640000@Atlassian.JIRA>
References: <JIRA.12640957.1469657640000@Atlassian.JIRA>
	<JIRA.12640957.1469657640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640957.1469657640000.102030.1512953040321@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski reassigned WFLY-6885:
------------------------------------

    Assignee: Tomasz Adamski


> Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-6885
>                 URL: https://issues.jboss.org/browse/WFLY-6885
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final
>            Reporter: Marcel Kolsteren
>            Assignee: Tomasz Adamski
>         Attachments: tx-timeout.zip
>
>
> The CMTTxInterceptor is responsible for starting a transaction if a public method is called on a session bean, and for ending it (commit or rollback) after the method has returned. If a runtime exception occurs during the execution of the public method, WildFly normally throws an EJBException with the original exception as cause. However, if the transaction has timed out, it swallows the original exception, and throws a EJBTransactionRolledBackException without a root cause. That obscures what actually happened during the execution of the public method.
> I attached a zip with an small Arquillian project that shows (1) what happens in case of an exception in combination with an active transaction (the succeeding test) and (2) what happens if the exception occurs when the transaction has timed out (the failing test).
> I think that the exception swallow is explainable as follows, referring to the 10.0.0.Final version of CMTTxInterceptor, that can be found here
> [https://github.com/wildfly/wildfly/blob/10.0.0.Final/ejb3/src/main/java/org/jboss/as/ejb3/tx/CMTTxInterceptor.java]
> This happens (I verified by stepping through the code with the debugger):
> * The catch block of invokeInOurTx is entered.
> * The method handleExceptionInOurTx tries to set the "rollback only" status on the transaction. The result is that the transaction, which has already been rolled back, stays in the rolled back state. A new EJBException is thrown, wrapping the original runtime exception.
> * The finally block of invokeInOurTx is entered.
> * The endTransaction method sees that the transaction is in the rolled back state, and concludes that the "reaper canceled (rolled back) tx case" is applicable. It throws a new exception (which replaces the EJBException that just has been thrown), but that new exception doesn't have a cause.
> The desired behavior would be that the interceptor only wraps the original exception in an EJBException in this case. I think that the invokeInOurTx method should only call the endTransaction method, if the transaction is not in the rolled back state.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 01:52:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 11 Dec 2017 01:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1370) CachingSecurityRealm and
 RealmIdentityCache missing TRACE logging
In-Reply-To: <JIRA.12712605.1505920818000@Atlassian.JIRA>
References: <JIRA.12712605.1505920818000@Atlassian.JIRA>
	<JIRA.12712605.1505920818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712605.1505920818000.102150.1512975120112@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503679#comment-13503679 ] 

Martin Choma commented on ELY-1370:
-----------------------------------

Thank you, this will be useful in troubleshooting issues.

> CachingSecurityRealm and RealmIdentityCache missing TRACE logging
> -----------------------------------------------------------------
>
>                 Key: ELY-1370
>                 URL: https://issues.jboss.org/browse/ELY-1370
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Realms
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta11
>
>
> Where caching is in use there is no TRACE logging showing the activity in the cache.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 02:01:00 2017
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 11 Dec 2017 02:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3448) Unable to set multiple ssl
 protocols and ciphers on security-realms using system properties
In-Reply-To: <JIRA.12723606.1512503096000@Atlassian.JIRA>
References: <JIRA.12723606.1512503096000@Atlassian.JIRA>
	<JIRA.12723606.1512503096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723606.1512503096000.102161.1512975660180@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated WFCORE-3448:
----------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2972, https://github.com/wildfly/wildfly-core/pull/2973  (was: https://github.com/wildfly/wildfly-core/pull/2972)


> Unable to set multiple ssl protocols and ciphers on security-realms using system properties
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3448
>                 URL: https://issues.jboss.org/browse/WFCORE-3448
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Derek Horton
>            Assignee: Brian Stansberry
>
> It is not possible to set the ssl protocol and ciphers on a security-realm using system property if multiple protocols and/or ciphers are needed.
> Setting the "enabled-cipher-suites" and  "enabled-protocols" using a system property works if the system property value resolves to a single value ("TLSv1.2" for example).
> An error is thrown if the system property has multiple values (-Dtlsversion="TLSv1.1 TLSv1.2").  Here is the error that is generated:
> 13:20:43,315 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: WFLYDM0096: No protocols in common, supported=([SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]), requested=([TLSv1.1 TLSv1.2])
>         at org.jboss.as.domain.management.security.SSLContextService.wrapSslContext(SSLContextService.java:137)
>         at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:102)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
>         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  Mon Dec 11 05:11:00 2017
From: issues at jboss.org (Vojtech Prusa (JIRA))
Date: Mon, 11 Dec 2017 05:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-34) Automation Testcase
In-Reply-To: <JIRA.12676683.1487083606000@Atlassian.JIRA>
References: <JIRA.12676683.1487083606000@Atlassian.JIRA>
	<JIRA.12676683.1487083606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676683.1487083606000.103192.1512987060628@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vojtech Prusa closed HAWKULARQE-34.
-----------------------------------
    Resolution: Out of Date


> Automation Testcase
> -------------------
>
>                 Key: HAWKULARQE-34
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-34
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Vojtech Prusa
>            Priority: Critical
>
> Smoke automation test to add new middleware provider with SSL and check that inventory is loaded.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 05:49:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Mon, 11 Dec 2017 05:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2163) [DMN Editor] Context table
 doesn't show entry type label if table is scrolled
In-Reply-To: <JIRA.12723671.1512545036000@Atlassian.JIRA>
References: <JIRA.12723671.1512545036000@Atlassian.JIRA>
	<JIRA.12723671.1512545036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723671.1512545036000.103396.1512989340244@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503823#comment-13503823 ] 

Michael Anstis commented on DROOLS-2163:
----------------------------------------

See https://github.com/manstis/kie-wb-common/commit/1cfeb6ad954a91cc8764f65e199ba725f7d23af4

> [DMN Editor] Context table doesn't show entry type label if table is scrolled
> -----------------------------------------------------------------------------
>
>                 Key: DROOLS-2163
>                 URL: https://issues.jboss.org/browse/DROOLS-2163
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>
> Context table offers 5 types of entries while each entry has label of its own type (Literal Expression, Function Relation etc.) However this label is not shown if the user scroll the table.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 05:49:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Mon, 11 Dec 2017 05:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2163) [DMN Editor] Context table
 doesn't show entry type label if table is scrolled
In-Reply-To: <JIRA.12723671.1512545036000@Atlassian.JIRA>
References: <JIRA.12723671.1512545036000@Atlassian.JIRA>
	<JIRA.12723671.1512545036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723671.1512545036000.103399.1512989340345@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis resolved DROOLS-2163.
------------------------------------
    Resolution: Done


> [DMN Editor] Context table doesn't show entry type label if table is scrolled
> -----------------------------------------------------------------------------
>
>                 Key: DROOLS-2163
>                 URL: https://issues.jboss.org/browse/DROOLS-2163
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>
> Context table offers 5 types of entries while each entry has label of its own type (Literal Expression, Function Relation etc.) However this label is not shown if the user scroll the table.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 06:52:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 11 Dec 2017 06:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2172) Segment split can cause the
 resulting segments to be associated to the wrong path
In-Reply-To: <JIRA.12724238.1512993075000@Atlassian.JIRA>
References: <JIRA.12724238.1512993075000@Atlassian.JIRA>
	<JIRA.12724238.1512993075564@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724238.1512993075000.103894.1512993120346@Atlassian.JIRA>

Mario Fusco created DROOLS-2172:
-----------------------------------

             Summary: Segment split can cause the resulting segments to be associated to the wrong path
                 Key: DROOLS-2172
                 URL: https://issues.jboss.org/browse/DROOLS-2172
             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  Mon Dec 11 06:52:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 11 Dec 2017 06:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2172) Segment split can cause the
 resulting segments to be associated to the wrong path
In-Reply-To: <JIRA.12724238.1512993076000@Atlassian.JIRA>
References: <JIRA.12724238.1512993076000@Atlassian.JIRA>
	<JIRA.12724238.1512993076000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724238.1512993076000.103897.1512993120441@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-2172:
-----------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> Segment split can cause the resulting segments to be associated to the wrong path
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-2172
>                 URL: https://issues.jboss.org/browse/DROOLS-2172
>             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  Mon Dec 11 06:52:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 11 Dec 2017 06:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2172) Segment split can cause the
 resulting segments to be associated to the wrong path
In-Reply-To: <JIRA.12724238.1512993076000@Atlassian.JIRA>
References: <JIRA.12724238.1512993076000@Atlassian.JIRA>
	<JIRA.12724238.1512993076000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724238.1512993076000.103900.1512993120501@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2172:
--------------------------------
    Component/s: core engine


> Segment split can cause the resulting segments to be associated to the wrong path
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-2172
>                 URL: https://issues.jboss.org/browse/DROOLS-2172
>             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 Dec 11 07:39:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 11 Dec 2017 07:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2172) Segment split can cause the
 resulting segments to be associated to the wrong path
In-Reply-To: <JIRA.12724238.1512993076000@Atlassian.JIRA>
References: <JIRA.12724238.1512993076000@Atlassian.JIRA>
	<JIRA.12724238.1512993076000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724238.1512993076000.104211.1512995940092@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503884#comment-13503884 ] 

Mario Fusco commented on DROOLS-2172:
-------------------------------------

If a segment split happens during an incremental compilation all the paths associated to the old segment are also associated to the new one regardless if the new segment actually belongs to that path or not. This may lead to spurious path linking and then to a NPE when the whole path is evaluated like the following

{code}
java.lang.NullPointerException
	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:114)
	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212)
	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87)
	at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34)
	at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43)
	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067)
	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)
{code}

> Segment split can cause the resulting segments to be associated to the wrong path
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-2172
>                 URL: https://issues.jboss.org/browse/DROOLS-2172
>             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 Dec 11 08:18:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 11 Dec 2017 08:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2172) Segment split can cause the
 resulting segments to be associated to the wrong path
In-Reply-To: <JIRA.12724238.1512993076000@Atlassian.JIRA>
References: <JIRA.12724238.1512993076000@Atlassian.JIRA>
	<JIRA.12724238.1512993076000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724238.1512993076000.104495.1512998280415@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2172:
--------------------------------
    Sprint: 2017 Week 49-50


> Segment split can cause the resulting segments to be associated to the wrong path
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-2172
>                 URL: https://issues.jboss.org/browse/DROOLS-2172
>             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 Dec 11 09:57:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 11 Dec 2017 09:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3453) Upgrade JBoss Build Tools
	to 1.2.3.Final
In-Reply-To: <JIRA.12724274.1513004164000@Atlassian.JIRA>
References: <JIRA.12724274.1513004164000@Atlassian.JIRA>
	<JIRA.12724274.1513004164402@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724274.1513004164000.105166.1513004220880@Atlassian.JIRA>

David Lloyd created WFCORE-3453:
-----------------------------------

             Summary: Upgrade JBoss Build Tools to 1.2.3.Final
                 Key: WFCORE-3453
                 URL: https://issues.jboss.org/browse/WFCORE-3453
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: David Lloyd
            Assignee: David Lloyd






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 09:57:01 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 11 Dec 2017 09:57:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9605) Upgrade JBoss Build Tools to
	1.2.3.Final
In-Reply-To: <JIRA.12724274.1513004164000@Atlassian.JIRA>
References: <JIRA.12724274.1513004164000@Atlassian.JIRA>
	<JIRA.12724274.1513004164000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724274.1513004164000.105182.1513004221406@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd moved WFCORE-3453 to WFLY-9605:
-------------------------------------------

    Project: WildFly  (was: WildFly Core)
        Key: WFLY-9605  (was: WFCORE-3453)


> Upgrade JBoss Build Tools to 1.2.3.Final
> ----------------------------------------
>
>                 Key: WFLY-9605
>                 URL: https://issues.jboss.org/browse/WFLY-9605
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 09:57:01 2017
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 11 Dec 2017 09:57:01 -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.105192.1513004221768@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503961#comment-13503961 ] 

Farah Juma commented on WFCORE-3396:
------------------------------------

Analysis Document:

https://developer.jboss.org/wiki/AnalysisDesign-IntegrationWithTheLetsEncryptCertificateAuthority

> 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-08



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 10:09:00 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 11 Dec 2017 10:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9606) Upgrade ejb-client to
	4.0.10.Final
In-Reply-To: <JIRA.12724281.1513004908000@Atlassian.JIRA>
References: <JIRA.12724281.1513004908000@Atlassian.JIRA>
	<JIRA.12724281.1513004908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724281.1513004908000.105365.1513004940930@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky moved JBEAP-13955 to WFLY-9606:
---------------------------------------------

          Project: WildFly  (was: JBoss Enterprise Application Platform)
              Key: WFLY-9606  (was: JBEAP-13955)
         Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
      Component/s: EJB
                       (was: EJB)
    Fix Version/s:     (was: 7.1.1.GA)


> Upgrade ejb-client to 4.0.10.Final
> ----------------------------------
>
>                 Key: WFLY-9606
>                 URL: https://issues.jboss.org/browse/WFLY-9606
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: EJB
>            Reporter: Ivo Studensky
>            Assignee: David Lloyd
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 10:17:01 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 11 Dec 2017 10:17:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9606) Upgrade ejb-client to
	4.0.10.Final
In-Reply-To: <JIRA.12724281.1513004908000@Atlassian.JIRA>
References: <JIRA.12724281.1513004908000@Atlassian.JIRA>
	<JIRA.12724281.1513004908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724281.1513004908000.105459.1513005421573@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503976#comment-13503976 ] 

David Lloyd commented on WFLY-9606:
-----------------------------------

There is no 4.0.10.Final.  Following the chain of links leads me to EJBCLIENT-253 which has been fixed since 4.0.2.Final.  Is there another JIRA that should be incorporated here?

> Upgrade ejb-client to 4.0.10.Final
> ----------------------------------
>
>                 Key: WFLY-9606
>                 URL: https://issues.jboss.org/browse/WFLY-9606
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: EJB
>            Reporter: Ivo Studensky
>            Assignee: David Lloyd
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 11:02:01 2017
From: issues at jboss.org (Anton Giertli (JIRA))
Date: Mon, 11 Dec 2017 11:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2173) Segment split can cause the
 resulting segments to be associated to the wrong path
In-Reply-To: <JIRA.12724299.1513008115000@Atlassian.JIRA>
References: <JIRA.12724299.1513008115000@Atlassian.JIRA>
	<JIRA.12724299.1513008115980@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724299.1513008115000.105840.1513008121142@Atlassian.JIRA>

Anton Giertli created DROOLS-2173:
-------------------------------------

             Summary: Segment split can cause the resulting segments to be associated to the wrong path
                 Key: DROOLS-2173
                 URL: https://issues.jboss.org/browse/DROOLS-2173
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Anton Giertli
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 11:14:00 2017
From: issues at jboss.org (=?UTF-8?Q?Bartosz_Spyrko-=C5=9Amietanko_=28JIRA=29?=)
Date: Mon, 11 Dec 2017 11:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9607) Remove
 DigestAuthenticationMechanism code duplication between Wildfly,
 Undertow and Elytron
In-Reply-To: <JIRA.12724303.1513008789000@Atlassian.JIRA>
References: <JIRA.12724303.1513008789000@Atlassian.JIRA>
	<JIRA.12724303.1513008789874@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724303.1513008789000.106017.1513008840321@Atlassian.JIRA>

Bartosz Spyrko-?mietanko created WFLY-9607:
----------------------------------------------

             Summary: Remove DigestAuthenticationMechanism code duplication between Wildfly, Undertow and Elytron
                 Key: WFLY-9607
                 URL: https://issues.jboss.org/browse/WFLY-9607
             Project: WildFly
          Issue Type: Enhancement
          Components: Security
    Affects Versions: 11.0.0.Final
            Reporter: Bartosz Spyrko-?mietanko
            Assignee: Darran Lofthouse


Digest authentication mechanism is currently implemented in 3 places - in Wildfly undertow subsystem (legacy web authentication), Undertow itself (web console authentication) and Elytron (web authentication).

Any issue found in one of those scenarios is likely to affect others requiring fixing multiple codebases - ideally there should be a single implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Dec 11 13:04:01 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Mon, 11 Dec 2017 13:04:01 -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.106801.1513015441337@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2154:
--------------------------------
    Description: 
*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.



  was:
*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.

*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.





> 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  Mon Dec 11 13:06:00 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Mon, 11 Dec 2017 13:06: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.106809.1513015560263@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504077#comment-13504077 ] 

Liz Clayton commented on DROOLS-2154:
-------------------------------------

[~tirelli] [~manstis] I added a Requirement to the jira based on our discussions. 

> 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  Mon Dec 11 13:25:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 11 Dec 2017 13:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9607) Remove
 DigestAuthenticationMechanism code duplication between Wildfly,
 Undertow and Elytron
In-Reply-To: <JIRA.12724303.1513008790000@Atlassian.JIRA>
References: <JIRA.12724303.1513008790000@Atlassian.JIRA>
	<JIRA.12724303.1513008790000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724303.1513008790000.106844.1513016700423@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504082#comment-13504082 ] 

Darran Lofthouse commented on WFLY-9607:
----------------------------------------

The legacy implementation is to support integration with the PicketBox login modules due to the differences in the APIs to get the required credentials into the LoginModule - PicketBox has been deprecated so that code is already deprecated.

The legacy security realms are now wrapped in Elytron components so the management interfaces use the Elytron implementation now and not the Undertow implementation.

So at this stage we only have two implementations actively in use but one of them is for legacy integration already deprecated to be removed at a future point.

> Remove DigestAuthenticationMechanism code duplication between Wildfly, Undertow and Elytron
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9607
>                 URL: https://issues.jboss.org/browse/WFLY-9607
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Security
>    Affects Versions: 11.0.0.Final
>            Reporter: Bartosz Spyrko-?mietanko
>            Assignee: Darran Lofthouse
>
> Digest authentication mechanism is currently implemented in 3 places - in Wildfly undertow subsystem (legacy web authentication), Undertow itself (web console authentication) and Elytron (web authentication).
> Any issue found in one of those scenarios is likely to affect others requiring fixing multiple codebases - ideally there should be a single implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Dec 11 15:40:00 2017
From: issues at jboss.org (Bob McWhirter (JIRA))
Date: Mon, 11 Dec 2017 15:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9608) WildFly Jandexification
 should explicitly ignore module-info.class
In-Reply-To: <JIRA.12724341.1513024765000@Atlassian.JIRA>
References: <JIRA.12724341.1513024765000@Atlassian.JIRA>
	<JIRA.12724341.1513024765716@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724341.1513024765000.107251.1513024800513@Atlassian.JIRA>

Bob McWhirter created WFLY-9608:
-----------------------------------

             Summary: WildFly Jandexification should explicitly ignore module-info.class
                 Key: WFLY-9608
                 URL: https://issues.jboss.org/browse/WFLY-9608
             Project: WildFly
          Issue Type: Enhancement
            Reporter: Bob McWhirter
            Assignee: Jason Greene


Sometimes dependencies have module-info.class.

When WildFly jandexes them, it burps a warning:

2017-12-11 15:04:20,124 WARN  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0003: Could not index class module-info.class at /content/microservice-session.war/WEB-INF/lib/asm-tree-6.0.jar: java.lang.IllegalStateException: Unknown tag! pos=3 poolCount = 12



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 15:46:00 2017
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Mon, 11 Dec 2017 15:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7524) Add Hibernate-Spatial to
 WildFly Feature Pack
In-Reply-To: <JIRA.12660230.1478620902000@Atlassian.JIRA>
References: <JIRA.12660230.1478620902000@Atlassian.JIRA>
	<JIRA.12660230.1478620902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660230.1478620902000.107277.1513025160258@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504127#comment-13504127 ] 

Sanne Grinovero commented on WFLY-7524:
---------------------------------------

Hi [~gesker],

I would be happy to help, but could you clarify what it is you're after?

I see various options:
* We could have the {{hibernate-orm}} module depend on an optional "spatial extensions" module w/o including it, and publish the missing module as a drop-in feature pack to be downloaded separately.
* We could simply include all missing dependencies into WildFly (although I suspect some people might not like that)
* We can enhance the feature packs which we release with each release of Hibernate ORM. 

See also: https://docs.jboss.org/hibernate/orm/5.2/topical/html_single/wildfly/Wildfly.html


> Add Hibernate-Spatial to WildFly Feature Pack
> ---------------------------------------------
>
>                 Key: WFLY-7524
>                 URL: https://issues.jboss.org/browse/WFLY-7524
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 11.0.0.Final, 12.0.0.Alpha1
>         Environment: Linux / OpenJDK 8 / Wildfly 11.0.0.Final
>            Reporter: Dennis Gesker
>            Assignee: Jason Greene
>              Labels: wildfly-feature-pack
>
> If possible kindly add jars need to make use of hibernate-spatial to WildFly-Feature-Pack
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> BTW, thank you for this package. It saves a HUGE amount of time with dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 17:43:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 11 Dec 2017 17:43:00 -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.107549.1513032180541@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned WFCORE-3019:
-------------------------------------

    Assignee: James Perkins


> 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.Alpha5
>
>
> 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  Mon Dec 11 17:45:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 11 Dec 2017 17:45:00 -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.107554.1513032300151@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504162#comment-13504162 ] 

James Perkins commented on WFCORE-3019:
---------------------------------------

I realize this probably isn't urgent, but I noticed today the dist doesn't produce the correct contents in it's zip. While that itself is a simple fix, it seems reasonable just to fix this all at once.

> 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.Alpha5
>
>
> 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  Mon Dec 11 17:59:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Dec 2017 17:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9436) Test suite misses any sort of
 smoke test for JSR-77 management bean availability
In-Reply-To: <JIRA.12715748.1507710476000@Atlassian.JIRA>
References: <JIRA.12715748.1507710476000@Atlassian.JIRA>
	<JIRA.12715748.1507710476000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12715748.1507710476000.107579.1513033140792@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-9436:
-----------------------------------
    Issue Type: Enhancement  (was: Bug)


> Test suite misses any sort of smoke test for JSR-77 management bean availability
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-9436
>                 URL: https://issues.jboss.org/browse/WFLY-9436
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Michal Jurc
>            Assignee: Jozef Cibik
>             Fix For: 12.0.0.Alpha1
>
>
> There is no test case present to check for availability of JSR-77 MEJBs.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 18:09:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Dec 2017 18:09:01 -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.107632.1513033741466@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504171#comment-13504171 ] 

Brian Stansberry commented on WFCORE-3019:
------------------------------------------

[~jamezp] It's probably good to check with [~aloubyansky] on this one (and WFLY-9007). What I describe here sounds like it would be more in line with how the new provisioning would want things done but he may some thoughts or could at least benefit as an FYI.

> 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.Alpha5
>
>
> 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  Mon Dec 11 18:14:00 2017
From: issues at jboss.org (Dennis Gesker (JIRA))
Date: Mon, 11 Dec 2017 18:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7524) Add Hibernate-Spatial to
 WildFly Feature Pack
In-Reply-To: <JIRA.12660230.1478620902000@Atlassian.JIRA>
References: <JIRA.12660230.1478620902000@Atlassian.JIRA>
	<JIRA.12660230.1478620902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660230.1478620902000.107649.1513034040261@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504172#comment-13504172 ] 

Dennis Gesker commented on WFLY-7524:
-------------------------------------

Thanks for taking a look at this ticket [Sanne Grinovero|https://issues.jboss.org/secure/ViewProfile.jspa?name=sannegrinovero]

I'm not sure I've done a project in the past couple years that didn't have some kind of spatial element to it so I'd love to see the dependencies in WildFly. But, it would be great if spatial was included in the feature pack even if it results in a larger war/ear -- so even it not included with the server.

But, you are right and I can see where some might cringe at those parts/extras that are part of the Hibernate project being included by default.

What typically been done in the past when a product that provides a standards compliant capability (JPA in this case) has a useful functionality beyond the standard? Or, put another way, I'll gladly go with the flow based on how this "kind" of thing has been resolved in the past.

So my 1, 2, 3 of the options you presented would be:

* We could simply include all missing dependencies into WildFly 
* We can enhance the feature packs which we release with each release of Hibernate ORM
* We could have the hibernate-orm module depend on an optional "spatial extensions" module w/o including it, and publish the missing module as a drop-in feature pack to be downloaded separately


I absolutely don't want to make any waves. And, I am grateful to even have attention on this item because I use these features/libs quite a bit.
Thank you SO much for even considering WFLY-7523 and WFLY-7524

Dennis




> Add Hibernate-Spatial to WildFly Feature Pack
> ---------------------------------------------
>
>                 Key: WFLY-7524
>                 URL: https://issues.jboss.org/browse/WFLY-7524
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 11.0.0.Final, 12.0.0.Alpha1
>         Environment: Linux / OpenJDK 8 / Wildfly 11.0.0.Final
>            Reporter: Dennis Gesker
>            Assignee: Jason Greene
>              Labels: wildfly-feature-pack
>
> If possible kindly add jars need to make use of hibernate-spatial to WildFly-Feature-Pack
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> BTW, thank you for this package. It saves a HUGE amount of time with dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 18:14:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 11 Dec 2017 18:14:00 -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.107652.1513034040375@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504173#comment-13504173 ] 

James Perkins commented on WFCORE-3019:
---------------------------------------

Okay will do. As of now the {{wildfly-dist-$version.zip}} only contains the {{bin/product.conf}} and the single product module. I was going to file a JIRA for that, but then found this and thought maybe we should fix it all at once. The fix for that issue is very simple and if we just want to fix that I can file a separate JIRA and do that.

> 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.Alpha5
>
>
> 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  Mon Dec 11 18:15:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 11 Dec 2017 18:15:00 -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.107655.1513034100105@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504173#comment-13504173 ] 

James Perkins edited comment on WFCORE-3019 at 12/11/17 6:14 PM:
-----------------------------------------------------------------

[~brian.stansberry] Okay will do. As of now the {{wildfly-dist-$version.zip}} only contains the {{bin/product.conf}} and the single product module. I was going to file a JIRA for that, but then found this and thought maybe we should fix it all at once. The fix for that issue is very simple and if we just want to fix that I can file a separate JIRA and do that.


was (Author: jamezp):
Okay will do. As of now the {{wildfly-dist-$version.zip}} only contains the {{bin/product.conf}} and the single product module. I was going to file a JIRA for that, but then found this and thought maybe we should fix it all at once. The fix for that issue is very simple and if we just want to fix that I can file a separate JIRA and do that.

> 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.Alpha5
>
>
> 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  Mon Dec 11 18:18:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Dec 2017 18:18:00 -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.107658.1513034280130@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504174#comment-13504174 ] 

Brian Stansberry commented on WFCORE-3019:
------------------------------------------

[~jamezp] Yeah, maybe a separate jira would be better. We release alphas frequently and if the dist is broken we should get that corrected ASAP.

Does full have the same problem? If not does https://github.com/wildfly/wildfly/pull/10689 introduce that problem?

> 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.Alpha5
>
>
> 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  Mon Dec 11 18:36:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 11 Dec 2017 18:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3454) The wildfly-core-dist does
 not produce an archive with the correct contents
In-Reply-To: <JIRA.12724361.1513035322000@Atlassian.JIRA>
References: <JIRA.12724361.1513035322000@Atlassian.JIRA>
	<JIRA.12724361.1513035322706@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724361.1513035322000.107674.1513035360325@Atlassian.JIRA>

James Perkins created WFCORE-3454:
-------------------------------------

             Summary: The wildfly-core-dist does not produce an archive with the correct contents
                 Key: WFCORE-3454
                 URL: https://issues.jboss.org/browse/WFCORE-3454
             Project: WildFly Core
          Issue Type: Bug
            Reporter: James Perkins
            Assignee: James Perkins


The {{assembly.xml}} in the {{wildfly-core-dist}} module produces a zip file with only the source contents. This results in an unusable distribution.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 18:37:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 11 Dec 2017 18:37:00 -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.107677.1513035420118@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504176#comment-13504176 ] 

James Perkins commented on WFCORE-3019:
---------------------------------------

Okay done, WFCORE-3454. I'll just fix it there and we can look at this later. Full should be okay, but I will double check that PR.

> 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.Alpha5
>
>
> 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  Mon Dec 11 19:17:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 11 Dec 2017 19:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9609) Avoid unnecessary marshalling
 of AddressableNode wherever possible
In-Reply-To: <JIRA.12724366.1513037780000@Atlassian.JIRA>
References: <JIRA.12724366.1513037780000@Atlassian.JIRA>
	<JIRA.12724366.1513037780794@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724366.1513037780000.107696.1513037820461@Atlassian.JIRA>

Paul Ferraro created WFLY-9609:
----------------------------------

             Summary: Avoid unnecessary marshalling of AddressableNode wherever possible
                 Key: WFLY-9609
                 URL: https://issues.jboss.org/browse/WFLY-9609
             Project: WildFly
          Issue Type: Enhancement
          Components: Clustering
    Affects Versions: 11.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


Serialization of an AddressableNode requires an additional 7 or 19 bytes (depending on whether the corresponding bind address is IPv4 or IPv6) as well as the logical name as a UTF-8 string; all on top of the 16 bytes required to serialize the JGroups/Infinispan address.

In most cases, this is completely unnecessary, as the Node can always be recreated from the address via a NodeFactory<Address>. 

Known offenders are:
* org.wildfly.clustering.server.registry.CacheRegistry which stores the Node as a cache key.
* org.wildfly.clustering.server.provider.CacheServiceProviderRegistry which stores a Set<Node> as a cache value.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 11 21:59:00 2017
From: issues at jboss.org (Alec Henninger (JIRA))
Date: Mon, 11 Dec 2017 21:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3054) getPlatformMBeanServer
 behaves badly when called from premain class such as jmxetric
In-Reply-To: <JIRA.12533815.1393864749000@Atlassian.JIRA>
References: <JIRA.12533815.1393864749000@Atlassian.JIRA>
	<JIRA.12533815.1393864749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533815.1393864749000.107774.1513047540786@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504183#comment-13504183 ] 

Alec Henninger commented on WFLY-3054:
--------------------------------------

FWIW I believe this can be roughly solved by waiting for the "javax.management.builder.initial" system property to be set before calling ManagementFactory.getPlatformMBeanServer(). jboss-modules sets it programmatically, and if the platform MBeanServer is initialized too soon, it won't be created using the custom builder: https://github.com/jboss-modules/jboss-modules/blob/1.x/src/main/java/org/jboss/modules/Main.java#L520

> getPlatformMBeanServer behaves badly when called from premain class such as jmxetric
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-3054
>                 URL: https://issues.jboss.org/browse/WFLY-3054
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMX
>    Affects Versions: JBoss AS7 7.1.1.Final
>            Reporter: dpocock
>            Assignee: Kabir Khan
>              Labels: jboss
>
> JMXetric is a management agent JAR loaded using the JVM argument 
> java -javaagent:$JARLIBS/jmxetric-1.0.2.jar .....
> In the premain method (executed before JBoss main() is invoked), jmxetric calls the static method:
>    ManagementFactory.getPlatformMBeanServer()
> This puts JMX into a bad state and the jboss.as tree is completely missing when browsed with jconsole
> As a workaround, jmxetric will defer the call to ManagementFactory.getPlatformMBeanServer() using the "initialdelay" parameter set to a value such as 20 seconds.
> However, it would be good if JBoss could act more cleanly in this situation, for example, throwing an exception if ManagementFactory.getPlatformMBeanServer() is called too early, or finding a way to add the "jboss.as" stuff later.
> The 1.0.6 release of jmxetric will include the workaround by default.  The bug can be reproduced by setting initialdelay="0" in the sample jmxetric.xml or using jmxetric 1.0.5
> jmxetric versions before 1.0.5 suffer from issues with the jboss logger as discussed in WFLY-895, so this issue was only discovered after removing the logging statements from jmxetric.
> Also covered in jmxetric github:
> https://github.com/ganglia/jmxetric/issues/9



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 01:37:00 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 01:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.107920.1513060620635@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shing Lam updated WFLY-9585:
----------------------------
    Attachment: jBosslookup.zip


> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 01:37:00 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 01:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.107923.1513060620983@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shing Lam updated WFLY-9585:
----------------------------
    Attachment: jBossLookup-ear-0.0.1-SNAPSHOT.ear


> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 02:57:00 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 02:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.108192.1513065420122@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shing Lam updated WFLY-9585:
----------------------------
    Attachment: jBossLookup-ear-0.0.1-SNAPSHOT.ear


> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 02:58:01 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 02:58:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.108195.1513065481171@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shing Lam updated WFLY-9585:
----------------------------
    Attachment: jboss-lookup.zip


> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 03:07:00 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 03:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.108232.1513066020150@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504245#comment-13504245 ] 

Shing Lam commented on WFLY-9585:
---------------------------------

I have trimmed down the essential minimum of our project to illustrate the issue.

we have a datasource to standalone.xml 

                <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
                    <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
                    <driver>com.mysql</driver>
                    <security>
                        <security-domain>encrypted-mysqlds-rm_uat</security-domain>
                    </security>
                    <validation>
                        <validate-on-match>false</validate-on-match>
                        <background-validation>false</background-validation>
                    </validation>
                    <statement>
                        <share-prepared-statements>false</share-prepared-statements>
                    </statement>
                </datasource>

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 




> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 03:09:00 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 03:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.108245.1513066140278@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504245#comment-13504245 ] 

Shing Lam edited comment on WFLY-9585 at 12/12/17 3:08 AM:
-----------------------------------------------------------

I have trimmed down the essential minimum of our project to illustrate the issue.

we have a datasource to standalone.xml 

 {{               <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
                    <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
                    <driver>com.mysql</driver>
                    <security>
                        <security-domain>encrypted-mysqlds-rm_uat</security-domain>
                    </security>
                    <validation>
                        <validate-on-match>false</validate-on-match>
                        <background-validation>false</background-validation>
                    </validation>
                    <statement>
                        <share-prepared-statements>false</share-prepared-statements>
                    </statement>
                </datasource>}}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{{           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>}}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 





was (Author: lam_shing):
I have trimmed down the essential minimum of our project to illustrate the issue.

we have a datasource to standalone.xml 

                <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
                    <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
                    <driver>com.mysql</driver>
                    <security>
                        <security-domain>encrypted-mysqlds-rm_uat</security-domain>
                    </security>
                    <validation>
                        <validate-on-match>false</validate-on-match>
                        <background-validation>false</background-validation>
                    </validation>
                    <statement>
                        <share-prepared-statements>false</share-prepared-statements>
                    </statement>
                </datasource>

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 




> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 03:12:00 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 03:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.108282.1513066320328@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504245#comment-13504245 ] 

Shing Lam edited comment on WFLY-9585 at 12/12/17 3:11 AM:
-----------------------------------------------------------

I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 42 kB), the older ones are obsolete.

we have a datasource to standalone.xml 

 {{               <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
                    <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
                    <driver>com.mysql</driver>
                    <security>
                        <security-domain>encrypted-mysqlds-rm_uat</security-domain>
                    </security>
                    <validation>
                        <validate-on-match>false</validate-on-match>
                        <background-validation>false</background-validation>
                    </validation>
                    <statement>
                        <share-prepared-statements>false</share-prepared-statements>
                    </statement>
                </datasource>}}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{{           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>}}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 





was (Author: lam_shing):
I have trimmed down the essential minimum of our project to illustrate the issue.

we have a datasource to standalone.xml 

 {{               <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
                    <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
                    <driver>com.mysql</driver>
                    <security>
                        <security-domain>encrypted-mysqlds-rm_uat</security-domain>
                    </security>
                    <validation>
                        <validate-on-match>false</validate-on-match>
                        <background-validation>false</background-validation>
                    </validation>
                    <statement>
                        <share-prepared-statements>false</share-prepared-statements>
                    </statement>
                </datasource>}}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{{           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>}}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 




> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 03:12:00 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 03:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.108285.1513066320511@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504245#comment-13504245 ] 

Shing Lam edited comment on WFLY-9585 at 12/12/17 3:11 AM:
-----------------------------------------------------------

I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 41 kB), the older ones are obsolete.

we have a datasource to standalone.xml 

 {{               <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
                    <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
                    <driver>com.mysql</driver>
                    <security>
                        <security-domain>encrypted-mysqlds-rm_uat</security-domain>
                    </security>
                    <validation>
                        <validate-on-match>false</validate-on-match>
                        <background-validation>false</background-validation>
                    </validation>
                    <statement>
                        <share-prepared-statements>false</share-prepared-statements>
                    </statement>
                </datasource>}}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{{           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>}}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 





was (Author: lam_shing):
I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 42 kB), the older ones are obsolete.

we have a datasource to standalone.xml 

 {{               <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
                    <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
                    <driver>com.mysql</driver>
                    <security>
                        <security-domain>encrypted-mysqlds-rm_uat</security-domain>
                    </security>
                    <validation>
                        <validate-on-match>false</validate-on-match>
                        <background-validation>false</background-validation>
                    </validation>
                    <statement>
                        <share-prepared-statements>false</share-prepared-statements>
                    </statement>
                </datasource>}}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{{           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>}}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 




> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 03:14:00 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 03:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.108305.1513066440437@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504245#comment-13504245 ] 

Shing Lam edited comment on WFLY-9585 at 12/12/17 3:13 AM:
-----------------------------------------------------------

I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 41 kB), the older ones are obsolete.

we have a datasource to standalone.xml 

{code:xml}
             <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
                    <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
                    <driver>com.mysql</driver>
                    <security>
                        <security-domain>encrypted-mysqlds-rm_uat</security-domain>
                    </security>
                    <validation>
                        <validate-on-match>false</validate-on-match>
                        <background-validation>false</background-validation>
                    </validation>
                    <statement>
                        <share-prepared-statements>false</share-prepared-statements>
                    </statement>
                </datasource>
{code}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

{code:xml}
           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
{code}

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{code:xml}
          <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
{code}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 





was (Author: lam_shing):
I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 41 kB), the older ones are obsolete.

we have a datasource to standalone.xml 

 {{               <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
                    <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
                    <driver>com.mysql</driver>
                    <security>
                        <security-domain>encrypted-mysqlds-rm_uat</security-domain>
                    </security>
                    <validation>
                        <validate-on-match>false</validate-on-match>
                        <background-validation>false</background-validation>
                    </validation>
                    <statement>
                        <share-prepared-statements>false</share-prepared-statements>
                    </statement>
                </datasource>}}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{{           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>}}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 




> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 03:17:00 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 03:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.108316.1513066620279@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504245#comment-13504245 ] 

Shing Lam edited comment on WFLY-9585 at 12/12/17 3:16 AM:
-----------------------------------------------------------

I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 41 kB), the older ones are obsolete.

we have a datasource to standalone.xml 

{code:xml}
 <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
  <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
  <driver>com.mysql</driver>
  <security>
    <security-domain>encrypted-mysqlds-rm_uat</security-domain>
  </security>
  <validation>
    <validate-on-match>false</validate-on-match>
    <background-validation>false</background-validation>
  </validation>
  <statement>
    <share-prepared-statements>false</share-prepared-statements>
  </statement>
</datasource>
{code}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

{code:xml}
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
{code}

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{code:xml}
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
{code}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 





was (Author: lam_shing):
I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 41 kB), the older ones are obsolete.

we have a datasource to standalone.xml 

{code:xml}
             <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
                    <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
                    <driver>com.mysql</driver>
                    <security>
                        <security-domain>encrypted-mysqlds-rm_uat</security-domain>
                    </security>
                    <validation>
                        <validate-on-match>false</validate-on-match>
                        <background-validation>false</background-validation>
                    </validation>
                    <statement>
                        <share-prepared-statements>false</share-prepared-statements>
                    </statement>
                </datasource>
{code}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

{code:xml}
           <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
{code}

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{code:xml}
          <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
{code}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 




> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 03:19:00 2017
From: issues at jboss.org (Shing Lam (JIRA))
Date: Tue, 12 Dec 2017 03:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9585) Wildfly 10 ignores
 jboss-ejb3.xml resource-ref lookup-name
In-Reply-To: <JIRA.12722869.1512016733000@Atlassian.JIRA>
References: <JIRA.12722869.1512016733000@Atlassian.JIRA>
	<JIRA.12722869.1512016733000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722869.1512016733000.108319.1513066740142@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504245#comment-13504245 ] 

Shing Lam edited comment on WFLY-9585 at 12/12/17 3:18 AM:
-----------------------------------------------------------

I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 41 kB), the older ones are obsolete.

we have a datasource to standalone.xml 

{code:xml}
 <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
  <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
  <driver>com.mysql</driver>
  <security>
    <security-domain>encrypted-mysqlds-rm_uat</security-domain>
  </security>
  <validation>
    <validate-on-match>false</validate-on-match>
    <background-validation>false</background-validation>
  </validation>
  <statement>
    <share-prepared-statements>false</share-prepared-statements>
  </statement>
</datasource>
{code}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

{code:xml}
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
{code}

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{code:xml}
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
{code}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection as there is no default datasource, but in wildfly-10, it get always wired to the default datasource, instead of following the dd.





was (Author: lam_shing):
I have trimmed down the essential minimum of our project to illustrate the issue. Please use the ear (27 kB) and source code (jboss-lookup.zip 41 kB), the older ones are obsolete.

we have a datasource to standalone.xml 

{code:xml}
 <datasource jta="true" jndi-name="java:jboss/jdbc/RMDataSource" pool-name="RMDataSource" enabled="true" use-ccm="false">
  <connection-url>jdbc:mysql://host:3306/schema?useUnicode=true&amp;amp;characterEncoding=utf8</connection-url>
  <driver>com.mysql</driver>
  <security>
    <security-domain>encrypted-mysqlds-rm_uat</security-domain>
  </security>
  <validation>
    <validate-on-match>false</validate-on-match>
    <background-validation>false</background-validation>
  </validation>
  <statement>
    <share-prepared-statements>false</share-prepared-statements>
  </statement>
</datasource>
{code}

If you deploy the ear to Wildfly-10, and point the broswer to http://localhost:8080/lookup/, and click the "get Connection Class", you'll see "com.mysql.jdbc.JDBC4Connection".
For Wildfly-10.1,if  the default datasource is set to java:jboss/jdbc/RMDataSource, you'll get com.mysql.jdbc.JDBC4Connection.

{code:xml}
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/jdbc/RMDataSource" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
{code}

if  default datasource is set to java:jboss/datasources/ExampleDS, you'll get org.h2.jdbc.JdbcConnection.

standalone.xml

{code:xml}
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:/JmsXA" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
{code}

In JBoss EAP 6.4, you always get com.mysql.jdbc.JDBC4Connection. 




> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
>                 Key: WFLY-9585
>                 URL: https://issues.jboss.org/browse/WFLY-9585
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>         Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
>            Reporter: Shing Lam
>            Assignee: Tomasz Adamski
>              Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>         Attachments: jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBossLookup-ear-0.0.1-SNAPSHOT.ear, jBosslookup.zip, jboss-lookup.zip
>
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used.  But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
>   <enterprise-beans>
>     <session>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <res-auth>Container</res-auth>
>         </resource-ref>
>         <persistence-context-ref>
>             <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
>         </persistence-context-ref>
>     </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
>   <jboss:enterprise-beans>
>     <jboss:ejb>
>         <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
>         <resource-ref>
>             <res-ref-name>jdbc/RMDataSource</res-ref-name>
>             <res-type>javax.sql.DataSource</res-type>
>             <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
>         </resource-ref>
>     </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 04:18:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 12 Dec 2017 04:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2170) Unhelful error message:
 "Unknown property" should not only mention the name of the property,
 but also the class on which it is expecting it (and the DRL line causing it)
In-Reply-To: <JIRA.12724147.1512750215000@Atlassian.JIRA>
References: <JIRA.12724147.1512750215000@Atlassian.JIRA>
	<JIRA.12724147.1512750215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724147.1512750215000.108778.1513070280205@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2170:
--------------------------------
    Sprint: 2017 Week 49-50


> Unhelful error message: "Unknown property" should not only mention the name of the property, but also the class on which it is expecting it (and the DRL line causing it)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2170
>                 URL: https://issues.jboss.org/browse/DROOLS-2170
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>
> I had no idea which class file it's expecting the room property on in this error message.
> I 'll needed to look for a needle in a haystack:
> {code}
> Caused by: java.lang.RuntimeException: Unknown property: room
> 	at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105)
> 	at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97)
> 	at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68)
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545)
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210)
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197)
> 	at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78)
> 	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37)
> 	at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27)
> 	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124)
> 	at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
> 	at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
> 	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329)
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324)
> 	at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at javax.swing.SwingWorker.run(SwingWorker.java:334)
> 	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)
> {code}
> Reproduce recipe: 
> - take meeting scheduling example in optaplanner-examplse
> - remove getters and setters for room in MeetingAssignment.java
> - remove all rules in the drl (to avoid it crashing on something else sooner), especially those that involve the room.
> - the error occurs when DroolsScoreDirector.update(meetingAssignment, "room") is called



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 04:35:05 2017
From: issues at jboss.org (Serg Pol (JIRA))
Date: Tue, 12 Dec 2017 04:35:05 -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.1513071287279@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.108901.1513071305104@Atlassian.JIRA>

Serg Pol created WFLY-9610:
------------------------------

             Summary: 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, Clustering
    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 Dec 12 05:49:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 12 Dec 2017 05:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2164) [DMN Editor] New Expression
 Columns doesn't respect width of parent column
In-Reply-To: <JIRA.12723701.1512550541000@Atlassian.JIRA>
References: <JIRA.12723701.1512550541000@Atlassian.JIRA>
	<JIRA.12723701.1512550541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723701.1512550541000.109261.1513075740711@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504353#comment-13504353 ] 

Michael Anstis commented on DROOLS-2164:
----------------------------------------

See https://github.com/manstis/kie-wb-common/commit/1b04a9ccfa218e5b4788b3db098ecff7b6f79e54

There were some other complications with {{FunctionGrid}} and {{RelationGrid}} that have also been fixed.

I also refactored the code a little to avoid use of {{instanceof}} when examining {{ExpressionCellValue}} values.

> [DMN Editor] New Expression Columns doesn't respect width of parent column
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-2164
>                 URL: https://issues.jboss.org/browse/DROOLS-2164
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>
> New Expression Column doesn't respect the width of the parent column in the context table. It can be seen if the context table contains multiple entries.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 05:49:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 12 Dec 2017 05:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2164) [DMN Editor] New Expression
 Columns doesn't respect width of parent column
In-Reply-To: <JIRA.12723701.1512550541000@Atlassian.JIRA>
References: <JIRA.12723701.1512550541000@Atlassian.JIRA>
	<JIRA.12723701.1512550541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723701.1512550541000.109264.1513075740803@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis resolved DROOLS-2164.
------------------------------------
    Resolution: Done


> [DMN Editor] New Expression Columns doesn't respect width of parent column
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-2164
>                 URL: https://issues.jboss.org/browse/DROOLS-2164
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>
> New Expression Column doesn't respect the width of the parent column in the context table. It can be seen if the context table contains multiple entries.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 06:06:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 12 Dec 2017 06:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2131) [DMN Editor] Boxed
 Expressions: Invocation editor
In-Reply-To: <JIRA.12720913.1510651966000@Atlassian.JIRA>
References: <JIRA.12720913.1510651966000@Atlassian.JIRA>
	<JIRA.12720913.1510651966000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720913.1510651966000.109378.1513076760449@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2131:
--------------------------------
    QE Status: ON_QA  (was: NEW)


> [DMN Editor] Boxed Expressions: Invocation editor
> -------------------------------------------------
>
>                 Key: DROOLS-2131
>                 URL: https://issues.jboss.org/browse/DROOLS-2131
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 07:27:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Tue, 12 Dec 2017 07:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-45) Don't set the transaction
	isolation level
In-Reply-To: <JIRA.12724430.1513081600000@Atlassian.JIRA>
References: <JIRA.12724430.1513081600000@Atlassian.JIRA>
	<JIRA.12724430.1513081600051@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724430.1513081600000.109886.1513081620831@Atlassian.JIRA>

Luis Barreiro created AG-45:
-------------------------------

             Summary: Don't set the transaction isolation level 
                 Key: AG-45
                 URL: https://issues.jboss.org/browse/AG-45
             Project: Agroal
          Issue Type: Bug
          Components: api
    Affects Versions: 0.3
            Reporter: Luis Barreiro
            Assignee: Luis Barreiro
             Fix For: 0.4


By default, the transaction isolation level should not be set. The JDBC driver will pick the default value.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 07:27:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Tue, 12 Dec 2017 07:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-45) Don't set the transaction
	isolation level
In-Reply-To: <JIRA.12724430.1513081600000@Atlassian.JIRA>
References: <JIRA.12724430.1513081600000@Atlassian.JIRA>
	<JIRA.12724430.1513081600000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724430.1513081600000.109889.1513081620993@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro resolved AG-45.
-----------------------------
    Resolution: Done


> Don't set the transaction isolation level 
> ------------------------------------------
>
>                 Key: AG-45
>                 URL: https://issues.jboss.org/browse/AG-45
>             Project: Agroal
>          Issue Type: Bug
>          Components: api
>    Affects Versions: 0.3
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.4
>
>
> By default, the transaction isolation level should not be set. The JDBC driver will pick the default value.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 07:38:02 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Tue, 12 Dec 2017 07:38:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-46) Fix intermitent failing tests
In-Reply-To: <JIRA.12724432.1513082252000@Atlassian.JIRA>
References: <JIRA.12724432.1513082252000@Atlassian.JIRA>
	<JIRA.12724432.1513082252717@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724432.1513082252000.109904.1513082282060@Atlassian.JIRA>

Luis Barreiro created AG-46:
-------------------------------

             Summary: Fix intermitent failing tests
                 Key: AG-46
                 URL: https://issues.jboss.org/browse/AG-46
             Project: Agroal
          Issue Type: Bug
          Components: test
    Affects Versions: 0.3
            Reporter: Luis Barreiro
            Assignee: Luis Barreiro
            Priority: Minor
             Fix For: 0.4


Increase the timeouts in BasicTests



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 07:39:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Tue, 12 Dec 2017 07:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-46) Fix intermitent failing tests
In-Reply-To: <JIRA.12724432.1513082253000@Atlassian.JIRA>
References: <JIRA.12724432.1513082253000@Atlassian.JIRA>
	<JIRA.12724432.1513082253000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724432.1513082253000.109909.1513082340353@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro resolved AG-46.
-----------------------------
    Resolution: Done


> Fix intermitent failing tests
> -----------------------------
>
>                 Key: AG-46
>                 URL: https://issues.jboss.org/browse/AG-46
>             Project: Agroal
>          Issue Type: Bug
>          Components: test
>    Affects Versions: 0.3
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>            Priority: Minor
>             Fix For: 0.4
>
>
> Increase the timeouts in BasicTests



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 07:51:00 2017
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Tue, 12 Dec 2017 07:51: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.109977.1513083060397@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504403#comment-13504403 ] 

Cheng Fang commented on WFLY-9610:
----------------------------------

starting a job execution is an async operation, so it is not guaranteed to run right away, but eventually the job execution should be running and records (job instance, job execution, step execution, and maybe partition execution) will be added to the job repository.  

endtime and exitStatus are not present in table probably because the job execution has not finished yet so these data are not available.

Have you tried running it on more recent versions of WildFly (version 10.1, or 11)?

> 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, Clustering
>    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 Dec 12 08:00:00 2017
From: issues at jboss.org (Umang Sharma (JIRA))
Date: Tue, 12 Dec 2017 08:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-206) Deadlock between
 AbstractWorkingMemory and DefaultAgenda
In-Reply-To: <JIRA.12497480.1375093239000@Atlassian.JIRA>
References: <JIRA.12497480.1375093239000@Atlassian.JIRA>
	<JIRA.12497480.1375093239000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497480.1375093239000.110009.1513083600784@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504412#comment-13504412 ] 

Umang Sharma commented on DROOLS-206:
-------------------------------------

I would like someone to reopen this issue. I am getting a similar deadlock. Using below dependencies:

		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-templates</artifactId>
			<version>${runtime.version}</version>
		</dependency>
		<dependency>
			<groupId>org.kie</groupId>
			<artifactId>kie-api</artifactId>
			<version>${runtime.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-core</artifactId>
			<version>${runtime.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-compiler</artifactId>
			<version>${runtime.version}</version>
		</dependency>

runtime.version = 6.5.0-Final

I have around 50 off threads stuck in a deadlock. 49 of them are having following stack trace:

"THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
        at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
        at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
        at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
        at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
        at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
        at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
 

And one of them is stuck in the following stack trace:

"THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
        at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
        at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
        at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
        at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
        at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
        at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
 
Please help us out in fixing this. Its a production system serving millions of users. 

PS: This is was reproduced under a medium load where we create 50 stateful sessions in parallel and also some rule were also getting added in the KieContainer at the same time.

> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
>                 Key: DROOLS-206
>                 URL: https://issues.jboss.org/browse/DROOLS-206
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.5.0.Final
>            Reporter: Winfried Umbrath
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.CR2
>
>         Attachments: jbrules-3700-test.tgz
>
>
> I experienced a deadlock when running in STREAM mode and using negative patterns with temporal constraints. 
> When the rule gets fired by the installed timer job and at the same time another thread is firing rules, a deadlock can occur:
> 1. [rule firing thread] StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:820)
> acquires lock in AbstractWorkingMemory
> 2. [timer-thread] DefaultAgenda.fireActivation()
> call of synchronized method
> 3. [rule firing thread] DefaultAgenda.fireActivation()
> synchronized method, wait for other thread to exit synchornized method
> 4. [timer-thread] AbstractWorkingMemory.getGlobal()
> tries to access a global, tries to acquire lock in AbstractWorkingMemory which is held by the other thread
> --> Deadlock
> Excerpt from thread dump:
> "http-thread-pool-8082(374)":
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1264)
> 	- waiting to lock <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> 	at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:679)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:234)
> 	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:102)
> 	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32)
> 	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
> 	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:821)
> "pool-4251-thread-1":
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  0x00007f503fc71a20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> 	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> 	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> 	at org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:634)
> 	at myrules.Rule_ruleWithTimeout_ece4a3c9fc2741a4ab97a92b77611203DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> 	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.DefaultAgenda.fireTimedActivation(DefaultAgenda.java:1344)
> 	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:83)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 08:00:01 2017
From: issues at jboss.org (Umang Sharma (JIRA))
Date: Tue, 12 Dec 2017 08:00:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2174) Deadlock between
 AbstractWorkingMemory and DefaultAgenda
In-Reply-To: <JIRA.12724437.1513083587000@Atlassian.JIRA>
References: <JIRA.12724437.1513083587000@Atlassian.JIRA>
	<JIRA.12724437.1513083587150@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724437.1513083587000.110013.1513083601033@Atlassian.JIRA>

Umang Sharma created DROOLS-2174:
------------------------------------

             Summary: Deadlock between AbstractWorkingMemory and DefaultAgenda
                 Key: DROOLS-2174
                 URL: https://issues.jboss.org/browse/DROOLS-2174
             Project: Drools
          Issue Type: Bug
    Affects Versions: 5.5.0.Final
            Reporter: Umang Sharma
            Assignee: Mario Fusco
             Fix For: 6.0.0.CR2


I experienced a deadlock when running in STREAM mode and using negative patterns with temporal constraints. 
When the rule gets fired by the installed timer job and at the same time another thread is firing rules, a deadlock can occur:

1. [rule firing thread] StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:820)
acquires lock in AbstractWorkingMemory

2. [timer-thread] DefaultAgenda.fireActivation()
call of synchronized method

3. [rule firing thread] DefaultAgenda.fireActivation()
synchronized method, wait for other thread to exit synchornized method

4. [timer-thread] AbstractWorkingMemory.getGlobal()
tries to access a global, tries to acquire lock in AbstractWorkingMemory which is held by the other thread

--> Deadlock


Excerpt from thread dump:

"http-thread-pool-8082(374)":
	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1264)
	- waiting to lock <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
	at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:679)
	at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:234)
	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:102)
	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32)
	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
	at org.drools.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:821)


"pool-4251-thread-1":
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  0x00007f503fc71a20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
	at org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:634)
	at myrules.Rule_ruleWithTimeout_ece4a3c9fc2741a4ab97a92b77611203DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
	at org.drools.common.DefaultAgenda.fireTimedActivation(DefaultAgenda.java:1344)
	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
	at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:83)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 08:00:01 2017
From: issues at jboss.org (Umang Sharma (JIRA))
Date: Tue, 12 Dec 2017 08:00:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2174) Deadlock between
 AbstractWorkingMemory and DefaultAgenda
In-Reply-To: <JIRA.12724437.1513083587000@Atlassian.JIRA>
References: <JIRA.12724437.1513083587000@Atlassian.JIRA>
	<JIRA.12724437.1513083587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724437.1513083587000.110016.1513083601171@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504413#comment-13504413 ] 

Umang Sharma commented on DROOLS-2174:
--------------------------------------

I would like someone to reopen this issue. I am getting a similar deadlock. Using below dependencies:
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-templates</artifactId>
<version>$
{runtime.version}</version>
</dependency>
<dependency>
<groupId>org.kie</groupId>
<artifactId>kie-api</artifactId>
<version>${runtime.version}
</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>$
{runtime.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>${runtime.version}
</version>
</dependency>
runtime.version = 6.5.0-Final
I have around 50 off threads stuck in a deadlock. 49 of them are having following stack trace:
"THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
And one of them is stuck in the following stack trace:
"THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
Please help us out in fixing this. Its a production system serving millions of users.
PS: This is was reproduced under a medium load where we create 50 stateful sessions in parallel and also some rule were also getting added in the KieContainer at the same time.

> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
>                 Key: DROOLS-2174
>                 URL: https://issues.jboss.org/browse/DROOLS-2174
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.5.0.Final
>            Reporter: Umang Sharma
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR2
>
>
> I experienced a deadlock when running in STREAM mode and using negative patterns with temporal constraints. 
> When the rule gets fired by the installed timer job and at the same time another thread is firing rules, a deadlock can occur:
> 1. [rule firing thread] StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:820)
> acquires lock in AbstractWorkingMemory
> 2. [timer-thread] DefaultAgenda.fireActivation()
> call of synchronized method
> 3. [rule firing thread] DefaultAgenda.fireActivation()
> synchronized method, wait for other thread to exit synchornized method
> 4. [timer-thread] AbstractWorkingMemory.getGlobal()
> tries to access a global, tries to acquire lock in AbstractWorkingMemory which is held by the other thread
> --> Deadlock
> Excerpt from thread dump:
> "http-thread-pool-8082(374)":
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1264)
> 	- waiting to lock <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> 	at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:679)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:234)
> 	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:102)
> 	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32)
> 	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
> 	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:821)
> "pool-4251-thread-1":
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  0x00007f503fc71a20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> 	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> 	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> 	at org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:634)
> 	at myrules.Rule_ruleWithTimeout_ece4a3c9fc2741a4ab97a92b77611203DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> 	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.DefaultAgenda.fireTimedActivation(DefaultAgenda.java:1344)
> 	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:83)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 08:02:02 2017
From: issues at jboss.org (Umang Sharma (JIRA))
Date: Tue, 12 Dec 2017 08:02:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2174) Deadlock between
 AbstractWorkingMemory and DefaultAgenda
In-Reply-To: <JIRA.12724437.1513083587000@Atlassian.JIRA>
References: <JIRA.12724437.1513083587000@Atlassian.JIRA>
	<JIRA.12724437.1513083587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724437.1513083587000.110027.1513083722390@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Umang Sharma updated DROOLS-2174:
---------------------------------
    Description: 
 I am getting a similar deadlock as the one in the cloned issue. We are using following dependencies:
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-templates</artifactId>
<version>$
{runtime.version}</version>
</dependency>
<dependency>
<groupId>org.kie</groupId>
<artifactId>kie-api</artifactId>
<version>${runtime.version}
</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>$
{runtime.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>${runtime.version}
</version>
</dependency>
runtime.version = 6.5.0-Final
I have around 50 off threads stuck in a deadlock. 49 of them are having following stack trace:
"THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
And one of them is stuck in the following stack trace:
"THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
Please help us out in fixing this. Its a production system serving millions of users.
PS: This is was reproduced under a medium load where we create 50 stateful sessions in parallel and also some rule were also getting added in the KieContainer at the same time.



  was:
I experienced a deadlock when running in STREAM mode and using negative patterns with temporal constraints. 
When the rule gets fired by the installed timer job and at the same time another thread is firing rules, a deadlock can occur:

1. [rule firing thread] StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:820)
acquires lock in AbstractWorkingMemory

2. [timer-thread] DefaultAgenda.fireActivation()
call of synchronized method

3. [rule firing thread] DefaultAgenda.fireActivation()
synchronized method, wait for other thread to exit synchornized method

4. [timer-thread] AbstractWorkingMemory.getGlobal()
tries to access a global, tries to acquire lock in AbstractWorkingMemory which is held by the other thread

--> Deadlock


Excerpt from thread dump:

"http-thread-pool-8082(374)":
	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1264)
	- waiting to lock <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
	at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:679)
	at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:234)
	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:102)
	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32)
	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
	at org.drools.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:821)


"pool-4251-thread-1":
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  0x00007f503fc71a20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
	at org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:634)
	at myrules.Rule_ruleWithTimeout_ece4a3c9fc2741a4ab97a92b77611203DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
	at org.drools.common.DefaultAgenda.fireTimedActivation(DefaultAgenda.java:1344)
	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
	at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:83)



> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
>                 Key: DROOLS-2174
>                 URL: https://issues.jboss.org/browse/DROOLS-2174
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.5.0.Final
>            Reporter: Umang Sharma
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR2
>
>
>  I am getting a similar deadlock as the one in the cloned issue. We are using following dependencies:
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-templates</artifactId>
> <version>$
> {runtime.version}</version>
> </dependency>
> <dependency>
> <groupId>org.kie</groupId>
> <artifactId>kie-api</artifactId>
> <version>${runtime.version}
> </version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-core</artifactId>
> <version>$
> {runtime.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <version>${runtime.version}
> </version>
> </dependency>
> runtime.version = 6.5.0-Final
> I have around 50 off threads stuck in a deadlock. 49 of them are having following stack trace:
> "THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
> at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
> And one of them is stuck in the following stack trace:
> "THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
> at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
> Please help us out in fixing this. Its a production system serving millions of users.
> PS: This is was reproduced under a medium load where we create 50 stateful sessions in parallel and also some rule were also getting added in the KieContainer at the same time.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 08:06:02 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 12 Dec 2017 08:06:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2174) Deadlock between
 AbstractWorkingMemory and DefaultAgenda
In-Reply-To: <JIRA.12724437.1513083587000@Atlassian.JIRA>
References: <JIRA.12724437.1513083587000@Atlassian.JIRA>
	<JIRA.12724437.1513083587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724437.1513083587000.110037.1513083962471@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504416#comment-13504416 ] 

Mario Fusco commented on DROOLS-2174:
-------------------------------------

Do you have a reproducer for this? Otherwise I don't see how I could investigate and eventually fix this problem.

> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
>                 Key: DROOLS-2174
>                 URL: https://issues.jboss.org/browse/DROOLS-2174
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.5.0.Final
>            Reporter: Umang Sharma
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR2
>
>
>  I am getting a similar deadlock as the one in the cloned issue. We are using following dependencies:
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-templates</artifactId>
> <version>$
> {runtime.version}</version>
> </dependency>
> <dependency>
> <groupId>org.kie</groupId>
> <artifactId>kie-api</artifactId>
> <version>${runtime.version}
> </version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-core</artifactId>
> <version>$
> {runtime.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <version>${runtime.version}
> </version>
> </dependency>
> runtime.version = 6.5.0-Final
> I have around 50 off threads stuck in a deadlock. 49 of them are having following stack trace:
> "THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
> at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
> And one of them is stuck in the following stack trace:
> "THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
> at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
> Please help us out in fixing this. Its a production system serving millions of users.
> PS: This is was reproduced under a medium load where we create 50 stateful sessions in parallel and also some rule were also getting added in the KieContainer at the same time.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 09:37:01 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 12 Dec 2017 09:37: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.110790.1513089421214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9610:
---------------------------------
    Component/s:     (was: Clustering)


> 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 Dec 12 09:52:02 2017
From: issues at jboss.org (Umang Sharma (JIRA))
Date: Tue, 12 Dec 2017 09:52:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2174) Deadlock between
 AbstractWorkingMemory and DefaultAgenda
In-Reply-To: <JIRA.12724437.1513083587000@Atlassian.JIRA>
References: <JIRA.12724437.1513083587000@Atlassian.JIRA>
	<JIRA.12724437.1513083587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724437.1513083587000.110897.1513090322450@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504497#comment-13504497 ] 

Umang Sharma commented on DROOLS-2174:
--------------------------------------

This is right from one of our production servers. I don't have a shareable reproducer for this as of now. Would require some work for get to that. Would try and provide it in few days time.

For now, I would request you to investigate it from the perspective of the cloned bug. Because the stack traces are exactly same. Also if some workarounds can be suggested that would be great. 

Another point is that we already have an application level lock in place to ensure that no sessions are created while some rules are getting added/modified. Si is there a way we can bypass the Drools internal locking mechanism?

Also I would also like to know any best practices while using stateful sessions.

> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
>                 Key: DROOLS-2174
>                 URL: https://issues.jboss.org/browse/DROOLS-2174
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.5.0.Final
>            Reporter: Umang Sharma
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR2
>
>
>  I am getting a similar deadlock as the one in the cloned issue. We are using following dependencies:
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-templates</artifactId>
> <version>$
> {runtime.version}</version>
> </dependency>
> <dependency>
> <groupId>org.kie</groupId>
> <artifactId>kie-api</artifactId>
> <version>${runtime.version}
> </version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-core</artifactId>
> <version>$
> {runtime.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <version>${runtime.version}
> </version>
> </dependency>
> runtime.version = 6.5.0-Final
> I have around 50 off threads stuck in a deadlock. 49 of them are having following stack trace:
> "THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
> at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
> And one of them is stuck in the following stack trace:
> "THREAD-4" #124 prio=5 os_prio=0 tid=0x00000000015fc800 nid=0x3a5d waiting on condition [0x00007fc773e7b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for <0x000000074d189818> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.drools.core.impl.KnowledgeBaseImpl.readLock(KnowledgeBaseImpl.java:703)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1434)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulSession(KnowledgeBaseImpl.java:1422)
> at org.drools.core.impl.KnowledgeBaseImpl.newStatefulKnowledgeSession(KnowledgeBaseImpl.java:308)
> at org.drools.core.impl.KnowledgeBaseImpl.newKieSession(KnowledgeBaseImpl.java:385)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:693)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:629)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:611)
> Please help us out in fixing this. Its a production system serving millions of users.
> PS: This is was reproduced under a medium load where we create 50 stateful sessions in parallel and also some rule were also getting added in the KieContainer at the same time.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 10:11:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 12 Dec 2017 10:11:00 -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.111011.1513091460372@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis moved GUVNOR-3486 to DROOLS-2175:
------------------------------------------------

              Project: Drools  (was: Guvnor)
                  Key: DROOLS-2175  (was: GUVNOR-3486)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
          Component/s: Guided Decision Table Editor
                           (was: Guided Decision Table)
    Affects Version/s: 7.3.0.Final
                           (was: 7.3.0.Final)
        Fix Version/s:     (was: 7.5.0.Final)


> [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 Dec 12 10:21:00 2017
From: issues at jboss.org (Erich Duda (JIRA))
Date: Tue, 12 Dec 2017 10:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9611) Support messaging
 export/import-journal for JDBC persistent store
In-Reply-To: <JIRA.12724479.1513091999000@Atlassian.JIRA>
References: <JIRA.12724479.1513091999000@Atlassian.JIRA>
	<JIRA.12724479.1513091999977@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724479.1513091999000.111057.1513092060576@Atlassian.JIRA>

Erich Duda created WFLY-9611:
--------------------------------

             Summary: Support messaging export/import-journal for JDBC persistent store
                 Key: WFLY-9611
                 URL: https://issues.jboss.org/browse/WFLY-9611
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 11.0.0.Final
            Reporter: Erich Duda
            Assignee: Jeff Mesnil
            Priority: Critical


In management model of Wildfly there are operations called import/export-journal which import/export messaging data from/to XML format. These operations are supported only for file based journal and they are not supported for JDBC based journal.

This feature is important for migration between persistence solutions and between versions of messaging brokers which use incompatible formats for storing messaging data.

XML exported from file based journal has to be able to import to JDBC based journal and vice versa.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 10:21:00 2017
From: issues at jboss.org (Erich Duda (JIRA))
Date: Tue, 12 Dec 2017 10:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9612) Support messaging
 export/import-journal for JDBC persistent store
In-Reply-To: <JIRA.12724480.1513092011000@Atlassian.JIRA>
References: <JIRA.12724480.1513092011000@Atlassian.JIRA>
	<JIRA.12724480.1513092011737@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724480.1513092011000.111061.1513092060716@Atlassian.JIRA>

Erich Duda created WFLY-9612:
--------------------------------

             Summary: Support messaging export/import-journal for JDBC persistent store
                 Key: WFLY-9612
                 URL: https://issues.jboss.org/browse/WFLY-9612
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 11.0.0.Final
            Reporter: Erich Duda
            Assignee: Jeff Mesnil
            Priority: Critical


In management model of Wildfly there are operations called import/export-journal which import/export messaging data from/to XML format. These operations are supported only for file based journal and they are not supported for JDBC based journal.

This feature is important for migration between persistence solutions and between versions of messaging brokers which use incompatible formats for storing messaging data.

XML exported from file based journal has to be able to import to JDBC based journal and vice versa.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 11:04:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 12 Dec 2017 11:04:00 -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.111257.1513094640635@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2149:
-----------------------------------
    Sprint: 2017 Week 49-50


> 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 Dec 12 11:05:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 12 Dec 2017 11:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-728) The map backing
 SimpleMapBackedSecurityRealm should be an identity map not a password map.
In-Reply-To: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.111261.1513094700540@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-728:
---------------------------
    Fix Version/s: 1.2.0.Beta11
                       (was: 1.2.0.Beta12)


> The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map.
> ------------------------------------------------------------------------------------------
>
>                 Key: ELY-728
>                 URL: https://issues.jboss.org/browse/ELY-728
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Realms
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.2.0.Beta11
>
>
> This realm is useful in cases where we need an identity to exist where the mechanism has performed validation without requiring access to credentials.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 11:31:01 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 12 Dec 2017 11:31:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9598) Clustering Testsuite 2.0: CLI, no ant,
 no XSLT, 3-node DIST testing
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.111443.1513096261001@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9598:
---------------------------------
    Description: 
Goals
* simplify test development
* make the testsuite manageable again

Steps to take
* move the testsuite away from using XSLT and just rely on the CLI scripts
* provide utility for configuring servers using CLI

  was:For starters, move the testsuite away from using XSLT and just rely on the CLI scripts. 



> Clustering Testsuite 2.0: CLI, no ant, no XSLT, 3-node DIST testing
> -------------------------------------------------------------------
>
>                 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
> 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  Tue Dec 12 11:32:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 12 Dec 2017 11:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9598) Clustering Testsuite 2.0: CLI, no ant,
 no XSLT, 3-node DIST testing
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.111446.1513096320207@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9598:
---------------------------------
    Description: 
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

  was:
Goals
* simplify test development
* make the testsuite manageable again

Steps to take
* move the testsuite away from using XSLT and just rely on the CLI scripts
* provide utility for configuring servers using CLI



> Clustering Testsuite 2.0: CLI, no ant, no XSLT, 3-node DIST testing
> -------------------------------------------------------------------
>
>                 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  Tue Dec 12 11:33:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 12 Dec 2017 11:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1461) Java 9: Eliminate reflection
 warning from security manager
In-Reply-To: <JIRA.12724492.1513096339000@Atlassian.JIRA>
References: <JIRA.12724492.1513096339000@Atlassian.JIRA>
	<JIRA.12724492.1513096339122@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724492.1513096339000.111449.1513096380126@Atlassian.JIRA>

David Lloyd created ELY-1461:
--------------------------------

             Summary: Java 9: Eliminate reflection warning from security manager
                 Key: ELY-1461
                 URL: https://issues.jboss.org/browse/ELY-1461
             Project: WildFly Elytron
          Issue Type: Task
          Components: Security Manager
            Reporter: David Lloyd
            Assignee: David Lloyd


Java 9 does not take kindly to our invasive reflection into AccessControlContext; also, if the implementation happens to not have the same fields, we fail to start the entire application server.

Our enhanced debug output is nice but for now this should be changed to be Java 9-safe.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 13:30:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 12 Dec 2017 13:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3455) Reduce unnecessary lambda
	usage
In-Reply-To: <JIRA.12724511.1513103358000@Atlassian.JIRA>
References: <JIRA.12724511.1513103358000@Atlassian.JIRA>
	<JIRA.12724511.1513103358795@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724511.1513103358000.111935.1513103400546@Atlassian.JIRA>

David Lloyd created WFCORE-3455:
-----------------------------------

             Summary: Reduce unnecessary lambda usage
                 Key: WFCORE-3455
                 URL: https://issues.jboss.org/browse/WFCORE-3455
             Project: WildFly Core
          Issue Type: Task
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 4.0.0.Alpha5


Lambdas chew up a lot of resources and we use a lot of them.  Eliminate whenever possible.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 13:30:01 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 12 Dec 2017 13:30:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3456) Reduce unnecessary lambda
	usage
In-Reply-To: <JIRA.12724512.1513103367000@Atlassian.JIRA>
References: <JIRA.12724512.1513103367000@Atlassian.JIRA>
	<JIRA.12724512.1513103367694@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724512.1513103367000.111938.1513103401095@Atlassian.JIRA>

David Lloyd created WFCORE-3456:
-----------------------------------

             Summary: Reduce unnecessary lambda usage
                 Key: WFCORE-3456
                 URL: https://issues.jboss.org/browse/WFCORE-3456
             Project: WildFly Core
          Issue Type: Task
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 4.0.0.Alpha5


Lambdas chew up a lot of resources and we use a lot of them.  Eliminate whenever possible.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 13:30:01 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 12 Dec 2017 13:30:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9613) Reduce unnecessary lambda
	usage
In-Reply-To: <JIRA.12724512.1513103368000@Atlassian.JIRA>
References: <JIRA.12724512.1513103368000@Atlassian.JIRA>
	<JIRA.12724512.1513103368000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724512.1513103368000.111942.1513103401912@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd moved WFCORE-3456 to WFLY-9613:
-------------------------------------------

          Project: WildFly  (was: WildFly Core)
              Key: WFLY-9613  (was: WFCORE-3456)
    Fix Version/s: 12.0.0.Alpha1
                       (was: 4.0.0.Alpha5)


> Reduce unnecessary lambda usage
> -------------------------------
>
>                 Key: WFLY-9613
>                 URL: https://issues.jboss.org/browse/WFLY-9613
>             Project: WildFly
>          Issue Type: Task
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 12.0.0.Alpha1
>
>
> Lambdas chew up a lot of resources and we use a lot of them.  Eliminate whenever possible.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 13:44:00 2017
From: issues at jboss.org (Guillaume Rousseau (JIRA))
Date: Tue, 12 Dec 2017 13:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-257)
 java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported
 major.minor version 52.0
In-Reply-To: <JIRA.12599060.1452598528000@Atlassian.JIRA>
References: <JIRA.12599060.1452598528000@Atlassian.JIRA>
	<JIRA.12599060.1452598528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599060.1452598528000.111968.1513104240960@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504598#comment-13504598 ] 

Guillaume Rousseau commented on JASSIST-257:
--------------------------------------------

Hello,

I have the same problem, Tried to recompile with ant but I need to find a version of ant where 1.7 is supported.

C:\Java\javassist-rel_3_21_0_ga>ant7
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/apache/tools/ant/launch/Launcher : Unsupported major.minor version 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)

Could you please provide us an url where we can find directly a version of javassist that is compatible with previous JDK ?

I would help a lot.


> java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0
> --------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-257
>                 URL: https://issues.jboss.org/browse/JASSIST-257
>             Project: Javassist
>          Issue Type: Release
>         Environment: Linux Tomcat 7 / JDK 1.6.0.41 / RHEL 5
> Javassist version 3.20.0-GA
>            Reporter: Simon Franquet
>            Assignee: Shigeru Chiba
>
> Sorry, not sure it's the right place to post this, but anyway : during instrumentation, class  transformation fails with the this :
>  Redefinition class failed !
> java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>         at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>         at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
>         at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>         at com.meilleuregestion.instrumentation.Transformer.transform(Transformer.java:33)
>         at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
>         at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>         at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>         at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2895)
>         at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173)
>         at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
>         at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
>         at org.apache.catalina.util.Introspection.loadClass(Introspection.java:143)
>         at org.apache.catalina.startup.WebAnnotationSet.loadApplicationServletAnnotations(WebAnnotationSet.java:135)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 17:08:00 2017
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 12 Dec 2017 17:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6464) JPA 2.2 Support
In-Reply-To: <JIRA.12612939.1459635658000@Atlassian.JIRA>
References: <JIRA.12612939.1459635658000@Atlassian.JIRA>
	<JIRA.12612939.1459635658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12612939.1459635658000.112256.1513116480608@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-6464:
-------------------------------
    Fix Version/s: 12.0.0.Alpha1


> JPA 2.2 Support
> ---------------
>
>                 Key: WFLY-6464
>                 URL: https://issues.jboss.org/browse/WFLY-6464
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 12 17:13:00 2017
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 12 Dec 2017 17:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6464) JPA 2.2 Support
In-Reply-To: <JIRA.12612939.1459635658000@Atlassian.JIRA>
References: <JIRA.12612939.1459635658000@Atlassian.JIRA>
	<JIRA.12612939.1459635658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12612939.1459635658000.112285.1513116780747@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-6464:
-------------------------------
    Description: 
>From JPA 2.2 specification appendix section A.1:
{code}
A.1 Maintenance Release Draft

Created document from Java Persistence 2.1 Final Release specification.

The following annotations have been marked @Repeatable:
 AssociationOverride
 AttributeOverride
 Convert
 JoinColumn
 MapKeyJoinColumn
 NamedEntityGraph
 NamedNativeQuery 
 NamedQuery
 NamedStoredProcedureQuery
 PersistenceContext
 PersistenceUnit
 PrimaryKeyJoinColumn
 SecondaryTable
 SqlResultSetMapping
 SequenceGenerator
 TableGenerator

Added SequenceGenerators and TableGenerators annotations.

Added support for CDI injection into AttributeConverter classes.

Added support for the mapping of the following java.time types:
 java.time.LocalDate
 java.time.LocalTime
 java.time.LocalDateTime
 java.time.OffsetTime
 java.time.OffsetDateTime

Added default Stream getResultStream() method to Query interface.

Added default Stream<X> getResultStream() method to TypedQuery interface.

Replaced reference to JAR file specification in persistence provider bootstrapping section with more

general reference to Java SE service provider requirements.

Updated persistence.xml and orm.xml schemas to 2.2 versions.

Updated Related Documents.
{code}


> JPA 2.2 Support
> ---------------
>
>                 Key: WFLY-6464
>                 URL: https://issues.jboss.org/browse/WFLY-6464
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 12.0.0.Alpha1
>
>
> From JPA 2.2 specification appendix section A.1:
> {code}
> A.1 Maintenance Release Draft
> Created document from Java Persistence 2.1 Final Release specification.
> The following annotations have been marked @Repeatable:
>  AssociationOverride
>  AttributeOverride
>  Convert
>  JoinColumn
>  MapKeyJoinColumn
>  NamedEntityGraph
>  NamedNativeQuery 
>  NamedQuery
>  NamedStoredProcedureQuery
>  PersistenceContext
>  PersistenceUnit
>  PrimaryKeyJoinColumn
>  SecondaryTable
>  SqlResultSetMapping
>  SequenceGenerator
>  TableGenerator
> Added SequenceGenerators and TableGenerators annotations.
> Added support for CDI injection into AttributeConverter classes.
> Added support for the mapping of the following java.time types:
>  java.time.LocalDate
>  java.time.LocalTime
>  java.time.LocalDateTime
>  java.time.OffsetTime
>  java.time.OffsetDateTime
> Added default Stream getResultStream() method to Query interface.
> Added default Stream<X> getResultStream() method to TypedQuery interface.
> Replaced reference to JAR file specification in persistence provider bootstrapping section with more
> general reference to Java SE service provider requirements.
> Updated persistence.xml and orm.xml schemas to 2.2 versions.
> Updated Related Documents.
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 03:17:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 13 Dec 2017 03:17:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9614) Make keystore optional in SSO
 configuration
In-Reply-To: <JIRA.12724588.1513152999000@Atlassian.JIRA>
References: <JIRA.12724588.1513152999000@Atlassian.JIRA>
	<JIRA.12724588.1513152999824@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724588.1513152999000.114820.1513153021374@Atlassian.JIRA>

Martin Choma created WFLY-9614:
----------------------------------

             Summary: Make keystore optional in SSO configuration
                 Key: WFLY-9614
                 URL: https://issues.jboss.org/browse/WFLY-9614
             Project: WildFly
          Issue Type: Bug
          Components: Security, Web (Undertow)
    Affects Versions: 11.0.0.Final
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


Keystore is required [1], thus signing logout message by default.
Questionable is if security brought by this is worth default command complexity as:
* Integrity of messages could be achieved on node to node communication level
* If message was not signed, attacker needs to know http session id to do a harm. Once attacker knows http session id, he can do a lot more useful attacks then logout user.

Some long communication on topic occured on Wildfly Elytron hipchat room 2017-12-7 - 2017-12-11.

[1] https://docs.jboss.org/author/display/WFLY/Web+Single+Sign-On




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 03:52:00 2017
From: issues at jboss.org (Serg Pol (JIRA))
Date: Wed, 13 Dec 2017 03: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.114939.1513155120208@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504757#comment-13504757 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

thanks. I can not reproduce this case no in cluster environment. Lokal is everything Ok.
Is it possible to see what has happened  in this case - if start of BatchJob was called, but BatchJob wasn't started? It happens sometimes.
May be to switch on some Log? 

just Wildfly 9.0.1.Final is used.

> 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 Dec 13 03:57:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Wed, 13 Dec 2017 03:57:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-212) Automation Testcase
In-Reply-To: <JIRA.12723743.1512562833000@Atlassian.JIRA>
References: <JIRA.12723743.1512562833000@Atlassian.JIRA>
	<JIRA.12723743.1512562833000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723743.1512562833000.114954.1513155421095@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan resolved HAWKULARQE-212.
---------------------------------------
    Release Notes Text: PR merged
            Resolution: Done


> Automation Testcase
> -------------------
>
>                 Key: HAWKULARQE-212
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-212
>             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  Wed Dec 13 05:02:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 13 Dec 2017 05:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.115262.1513159321090@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-609:
---------------------------
    Fix Version/s: 1.2.0.Beta11
                       (was: 1.2.0.Beta12)


> Unguarded read in ElytronPolicyConfiguration
> --------------------------------------------
>
>                 Key: ELY-609
>                 URL: https://issues.jboss.org/browse/ELY-609
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta7
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>              Labels: static_analysis
>             Fix For: 1.2.0.Beta11
>
>
> Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 05:51:01 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 13 Dec 2017 05:51:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2163) [DMN Editor] Context table
 doesn't show entry type label if table is scrolled
In-Reply-To: <JIRA.12723671.1512545036000@Atlassian.JIRA>
References: <JIRA.12723671.1512545036000@Atlassian.JIRA>
	<JIRA.12723671.1512545036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723671.1512545036000.115751.1513162261046@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2163:
--------------------------------
    QE Status: VERIFIED  (was: ON_QA)


> [DMN Editor] Context table doesn't show entry type label if table is scrolled
> -----------------------------------------------------------------------------
>
>                 Key: DROOLS-2163
>                 URL: https://issues.jboss.org/browse/DROOLS-2163
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>
> Context table offers 5 types of entries while each entry has label of its own type (Literal Expression, Function Relation etc.) However this label is not shown if the user scroll the table.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 05:52:01 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 13 Dec 2017 05:52:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2163) [DMN Editor] Context table
 doesn't show entry type label if table is scrolled
In-Reply-To: <JIRA.12723671.1512545036000@Atlassian.JIRA>
References: <JIRA.12723671.1512545036000@Atlassian.JIRA>
	<JIRA.12723671.1512545036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723671.1512545036000.115761.1513162321189@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504853#comment-13504853 ] 

Jozef Marko commented on DROOLS-2163:
-------------------------------------

Coverage extended slightly https://github.com/manstis/kie-wb-common/pull/20

> [DMN Editor] Context table doesn't show entry type label if table is scrolled
> -----------------------------------------------------------------------------
>
>                 Key: DROOLS-2163
>                 URL: https://issues.jboss.org/browse/DROOLS-2163
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>
> Context table offers 5 types of entries while each entry has label of its own type (Literal Expression, Function Relation etc.) However this label is not shown if the user scroll the table.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 06:34:01 2017
From: issues at jboss.org (Martin Mazanek (JIRA))
Date: Wed, 13 Dec 2017 06:34:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration
 uniqueness enhancements
In-Reply-To: <JIRA.12675329.1486478892000@Atlassian.JIRA>
References: <JIRA.12675329.1486478892000@Atlassian.JIRA>
	<JIRA.12675329.1486478892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675329.1486478892000.115940.1513164841276@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Mazanek reassigned ELY-929:
----------------------------------

    Assignee: Martin Mazanek


> AuthenticationConfiguration uniqueness enhancements
> ---------------------------------------------------
>
>                 Key: ELY-929
>                 URL: https://issues.jboss.org/browse/ELY-929
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Assignee: Martin Mazanek
>             Fix For: 1.2.0.Beta12
>
>
> Apply some enhancements to AuthenticationConfiguration uniqueness.
> * Add admonishing JavaDoc to {{useCallbackHandler}} to point out the importance of per-identity uniqueness of the callback handler
> The following also may be possible and useful:
> * Modify the {{AuthenticationConfiguration}} process to capture instances for {{Supplier}}-driven components at the time the configuration is used via the {{AuthenticationContextConfigurationClient}}
> * Add a variation of {{useCallbackHandler}} which accepts a {{Supplier<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 06:37:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 13 Dec 2017 06:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9614) Make keystore optional in SSO
 configuration
In-Reply-To: <JIRA.12724588.1513153000000@Atlassian.JIRA>
References: <JIRA.12724588.1513153000000@Atlassian.JIRA>
	<JIRA.12724588.1513153000000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724588.1513153000000.115984.1513165020787@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-9614:
--------------------------------------

    Assignee:     (was: Darran Lofthouse)


> Make keystore optional in SSO configuration
> -------------------------------------------
>
>                 Key: WFLY-9614
>                 URL: https://issues.jboss.org/browse/WFLY-9614
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 11.0.0.Final
>            Reporter: Martin Choma
>
> Keystore is required [1], thus signing logout message by default.
> Questionable is if security brought by this is worth default command complexity as:
> * Integrity of messages could be achieved on node to node communication level
> * If message was not signed, attacker needs to know http session id to do a harm. Once attacker knows http session id, he can do a lot more useful attacks then logout user.
> Some long communication on topic occured on Wildfly Elytron hipchat room 2017-12-7 - 2017-12-11.
> [1] https://docs.jboss.org/author/display/WFLY/Web+Single+Sign-On



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 07:19:00 2017
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Wed, 13 Dec 2017 07:19: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.116189.1513167540212@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504896#comment-13504896 ] 

Cheng Fang commented on WFLY-9610:
----------------------------------

you can try set the batch subsystem thread pool max size to be a small number (but not too small),  e.g., 3, start a long-running batch job execution, check if it's started, and start the job a second time, check if it's started, and so on.  When not enough batch threads are available, the job execution will be put on hold.

You can check batch status to see its progress: STARTED means it's already started; STARTING means it has been received but has not been started yet.

You can also use a debugger to see the progress of the job execution.

> 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 Dec 13 07:20:00 2017
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Wed, 13 Dec 2017 07: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.116198.1513167600817@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504896#comment-13504896 ] 

Cheng Fang edited comment on WFLY-9610 at 12/13/17 7:19 AM:
------------------------------------------------------------

you can try set the batch subsystem thread pool max size to be a small number (but not too small),  e.g., 3, start a long-running batch job execution, check if it's started, and start the job a second time, check if it's started, and so on.  When not enough batch threads are available, the job execution will be put on hold.

You can check batch status to see its progress: STARTED means it's already started; STARTING means it has been received but has not been started yet.  This can be done via WildFly CLI, or Web Console, or from your application code.

You can also use a debugger to see the progress of the job execution.


was (Author: cfang):
you can try set the batch subsystem thread pool max size to be a small number (but not too small),  e.g., 3, start a long-running batch job execution, check if it's started, and start the job a second time, check if it's started, and so on.  When not enough batch threads are available, the job execution will be put on hold.

You can check batch status to see its progress: STARTED means it's already started; STARTING means it has been received but has not been started yet.

You can also use a debugger to see the progress of the job execution.

> 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 Dec 13 07:35:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 13 Dec 2017 07:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3457) Minimise Classes in the
 Elytron Subsystem
In-Reply-To: <JIRA.12724639.1513168462000@Atlassian.JIRA>
References: <JIRA.12724639.1513168462000@Atlassian.JIRA>
	<JIRA.12724639.1513168462151@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724639.1513168462000.116302.1513168500790@Atlassian.JIRA>

Darran Lofthouse created WFCORE-3457:
----------------------------------------

             Summary: Minimise 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.Alpha5


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.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 07:40:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 13 Dec 2017 07:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1462) Move programatic
 authentication from Elytron Web to Elytron
In-Reply-To: <JIRA.12724645.1513168783000@Atlassian.JIRA>
References: <JIRA.12724645.1513168783000@Atlassian.JIRA>
	<JIRA.12724645.1513168783593@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724645.1513168783000.116365.1513168800510@Atlassian.JIRA>

Darran Lofthouse created ELY-1462:
-------------------------------------

             Summary: Move programatic authentication from Elytron Web to Elytron
                 Key: ELY-1462
                 URL: https://issues.jboss.org/browse/ELY-1462
             Project: WildFly Elytron
          Issue Type: Task
          Components: HTTP
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.2.0.Beta11


The core implementation should be following the same pattern as is followed for mechanisms such as FORM authentication, this should not need to live within the HTTP server integration project.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 07:41:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 13 Dec 2017 07:41:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1463) Programatic authentication is
 not creating a HTTP session if one does not already exist.
In-Reply-To: <JIRA.12724646.1513168825000@Atlassian.JIRA>
References: <JIRA.12724646.1513168825000@Atlassian.JIRA>
	<JIRA.12724646.1513168825521@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724646.1513168825000.116375.1513168861763@Atlassian.JIRA>

Darran Lofthouse created ELY-1463:
-------------------------------------

             Summary: Programatic authentication is not creating a HTTP session if one does not already exist.
                 Key: ELY-1463
                 URL: https://issues.jboss.org/browse/ELY-1463
             Project: WildFly Elytron
          Issue Type: Bug
          Components: HTTP
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.2.0.Beta11






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 07:43:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 13 Dec 2017 07:43:00 -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.1513168930000@Atlassian.JIRA>
References: <JIRA.12724648.1513168930000@Atlassian.JIRA>
	<JIRA.12724648.1513168930953@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724648.1513168930000.116393.1513168980630@Atlassian.JIRA>

Darran Lofthouse created ELY-1464:
-------------------------------------

             Summary: 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.Beta11


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  Wed Dec 13 08:18:00 2017
From: issues at jboss.org (Martin Mazanek (JIRA))
Date: Wed, 13 Dec 2017 08:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1386) <certificate-revocation-list
 /> should also support a URI and resource in addition to path.
In-Reply-To: <JIRA.12714964.1507288406000@Atlassian.JIRA>
References: <JIRA.12714964.1507288406000@Atlassian.JIRA>
	<JIRA.12714964.1507288406000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12714964.1507288406000.116634.1513171080543@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Mazanek reassigned ELY-1386:
-----------------------------------

    Assignee: Martin Mazanek


> <certificate-revocation-list /> should also support a URI and resource in addition to path.
> -------------------------------------------------------------------------------------------
>
>                 Key: ELY-1386
>                 URL: https://issues.jboss.org/browse/ELY-1386
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Assignee: Martin Mazanek
>             Fix For: 1.2.0.Beta11
>
>
> KeyStores can be loaded from a path, a URI, or as a resource - the certificate revocation list should be the same.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 08:19:01 2017
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Wed, 13 Dec 2017 08:19:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7524) Add Hibernate-Spatial to
 WildFly Feature Pack
In-Reply-To: <JIRA.12660230.1478620902000@Atlassian.JIRA>
References: <JIRA.12660230.1478620902000@Atlassian.JIRA>
	<JIRA.12660230.1478620902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660230.1478620902000.116663.1513171141241@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504933#comment-13504933 ] 

Sanne Grinovero commented on WFLY-7524:
---------------------------------------

Thanks for the feedback [~gesker]!

I've opened https://hibernate.atlassian.net/browse/HHH-12163 after discussing this with the Hibernate team.
We'll start by including the misisng bits into the modules we release with Hibernate ORM releases, we can later see if the WildFly team wants to incorporate these too.

https://hibernate.atlassian.net/browse/HHH-12163

> Add Hibernate-Spatial to WildFly Feature Pack
> ---------------------------------------------
>
>                 Key: WFLY-7524
>                 URL: https://issues.jboss.org/browse/WFLY-7524
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 11.0.0.Final, 12.0.0.Alpha1
>         Environment: Linux / OpenJDK 8 / Wildfly 11.0.0.Final
>            Reporter: Dennis Gesker
>            Assignee: Jason Greene
>              Labels: wildfly-feature-pack
>
> If possible kindly add jars need to make use of hibernate-spatial to WildFly-Feature-Pack
> org.hibernate:hibernate-spatial 
> org.geolatte:geolatte-geom
> com.vividsolutions:jts-parent
> BTW, thank you for this package. It saves a HUGE amount of time with dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 08:23:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Wed, 13 Dec 2017 08:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-213) Automate JMAN4-196
In-Reply-To: <JIRA.12724657.1513171355000@Atlassian.JIRA>
References: <JIRA.12724657.1513171355000@Atlassian.JIRA>
	<JIRA.12724657.1513171355802@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724657.1513171355000.116686.1513171380502@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-213:
-----------------------------------------

             Summary: Automate JMAN4-196
                 Key: HAWKULARQE-213
                 URL: https://issues.jboss.org/browse/HAWKULARQE-213
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Hayk Hovsepyan
            Assignee: Hayk Hovsepyan


https://issues.jboss.org/browse/JMAN4-196



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 10:39:00 2017
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Wed, 13 Dec 2017 10:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-257)
 java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported
 major.minor version 52.0
In-Reply-To: <JIRA.12599060.1452598528000@Atlassian.JIRA>
References: <JIRA.12599060.1452598528000@Atlassian.JIRA>
	<JIRA.12599060.1452598528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599060.1452598528000.117921.1513179540621@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505052#comment-13505052 ] 

Shigeru Chiba commented on JASSIST-257:
---------------------------------------

Try [this|https://github.com/jboss-javassist/javassist/releases].

> java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0
> --------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-257
>                 URL: https://issues.jboss.org/browse/JASSIST-257
>             Project: Javassist
>          Issue Type: Release
>         Environment: Linux Tomcat 7 / JDK 1.6.0.41 / RHEL 5
> Javassist version 3.20.0-GA
>            Reporter: Simon Franquet
>            Assignee: Shigeru Chiba
>
> Sorry, not sure it's the right place to post this, but anyway : during instrumentation, class  transformation fails with the this :
>  Redefinition class failed !
> java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>         at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>         at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
>         at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>         at com.meilleuregestion.instrumentation.Transformer.transform(Transformer.java:33)
>         at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
>         at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>         at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>         at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2895)
>         at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173)
>         at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
>         at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
>         at org.apache.catalina.util.Introspection.loadClass(Introspection.java:143)
>         at org.apache.catalina.startup.WebAnnotationSet.loadApplicationServletAnnotations(WebAnnotationSet.java:135)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 10:54:00 2017
From: issues at jboss.org (Lance Leverich (JIRA))
Date: Wed, 13 Dec 2017 10:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2176) Add ability to use
 KieRuntimeLogger with RuleUnits
In-Reply-To: <JIRA.12724711.1513180403000@Atlassian.JIRA>
References: <JIRA.12724711.1513180403000@Atlassian.JIRA>
	<JIRA.12724711.1513180403184@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724711.1513180403000.118037.1513180440275@Atlassian.JIRA>

Lance Leverich created DROOLS-2176:
--------------------------------------

             Summary: Add ability to use KieRuntimeLogger with RuleUnits
                 Key: DROOLS-2176
                 URL: https://issues.jboss.org/browse/DROOLS-2176
             Project: Drools
          Issue Type: Enhancement
          Components: core engine
            Reporter: Lance Leverich
            Assignee: Lance Leverich
            Priority: Minor


Need to be able to use the KieRuntimeLogger with RuleUnits, so that the rule debugging can be more effective.

The mechanism for doing this should be exposed via the InternalRuleUnitExecutor interface.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 11:07:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Wed, 13 Dec 2017 11:07:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1465) External CS,
 PKCS11 can't be configured with externalPath
In-Reply-To: <JIRA.12724714.1513181174000@Atlassian.JIRA>
References: <JIRA.12724714.1513181174000@Atlassian.JIRA>
	<JIRA.12724714.1513181174239@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724714.1513181174000.118122.1513181221407@Atlassian.JIRA>

Ilia Vassilev created ELY-1465:
----------------------------------

             Summary: External CS, PKCS11 can't be configured with externalPath 
                 Key: ELY-1465
                 URL: https://issues.jboss.org/browse/ELY-1465
             Project: WildFly Elytron
          Issue Type: Bug
          Components: KeyStores
    Affects Versions: 1.2.0.Beta10
            Reporter: Ilia Vassilev
            Assignee: Ilia Vassilev
            Priority: Critical


To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.

{code}
10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
	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.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
	at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
	... 5 more
Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
	at java.nio.file.Files.newByteChannel(Files.java:361)
	at java.nio.file.Files.newByteChannel(Files.java:407)
	at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
	at java.nio.file.Files.newInputStream(Files.java:152)
	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
	... 9 more

10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("credential-store" => "fips-credential-store")
]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
    Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
    Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
{code}

Problem seems to be in method
{code:java|title=KeyStoreCredentialStore.java}
    private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
        KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
        keyStore = getKeyStoreInstance("JCEKS");
        externalStorage = new ExternalStorage();
        try {
            final char[] storePassword = getStorePassword(protectionParameter);
            if (keyContainingKeyStoreLocation != null) {
                try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
                    keyContainingKeyStore.load(is, storePassword);
                }
            } else {
                // keystore without file (e.g. PKCS11)
                synchronized (EmptyProvider.getInstance()) {
                    keyContainingKeyStore.load(null, storePassword);
                }
            }
            externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
        } catch(IOException | GeneralSecurityException e) {
            throw log.cannotInitializeCredentialStore(e);
        }
    }
{code}

Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 11:08:02 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Wed, 13 Dec 2017 11:08:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3458) External CS,
 PKCS11 can't be configured with externalPath
In-Reply-To: <JIRA.12724714.1513181174000@Atlassian.JIRA>
References: <JIRA.12724714.1513181174000@Atlassian.JIRA>
	<JIRA.12724714.1513181174000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724714.1513181174000.118178.1513181282086@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved ELY-1465 to WFCORE-3458:
--------------------------------------------

              Project: WildFly Core  (was: WildFly Elytron)
                  Key: WFCORE-3458  (was: ELY-1465)
          Component/s: Security
                           (was: KeyStores)
    Affects Version/s: 4.0.0.Alpha4
                           (was: 1.2.0.Beta10)


> External CS, PKCS11 can't be configured with externalPath 
> ----------------------------------------------------------
>
>                 Key: WFCORE-3458
>                 URL: https://issues.jboss.org/browse/WFCORE-3458
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 4.0.0.Alpha4
>            Reporter: Ilia Vassilev
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 	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.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> 	at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> 	... 5 more
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 	at java.nio.file.Files.newByteChannel(Files.java:361)
> 	at java.nio.file.Files.newByteChannel(Files.java:407)
> 	at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> 	at java.nio.file.Files.newInputStream(Files.java:152)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> 	... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
>     Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
>     Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
>     private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
>         KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
>         keyStore = getKeyStoreInstance("JCEKS");
>         externalStorage = new ExternalStorage();
>         try {
>             final char[] storePassword = getStorePassword(protectionParameter);
>             if (keyContainingKeyStoreLocation != null) {
>                 try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
>                     keyContainingKeyStore.load(is, storePassword);
>                 }
>             } else {
>                 // keystore without file (e.g. PKCS11)
>                 synchronized (EmptyProvider.getInstance()) {
>                     keyContainingKeyStore.load(null, storePassword);
>                 }
>             }
>             externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
>         } catch(IOException | GeneralSecurityException e) {
>             throw log.cannotInitializeCredentialStore(e);
>         }
>     }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 11:11:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Wed, 13 Dec 2017 11:11:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3458) External CS,
 PKCS11 can't be configured with externalPath
In-Reply-To: <JIRA.12724714.1513181174000@Atlassian.JIRA>
References: <JIRA.12724714.1513181174000@Atlassian.JIRA>
	<JIRA.12724714.1513181174000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724714.1513181174000.118200.1513181461386@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated WFCORE-3458:
----------------------------------
    Git Pull Request:   (was: https://github.com/wildfly-security/wildfly-elytron/pull/1051)


> External CS, PKCS11 can't be configured with externalPath 
> ----------------------------------------------------------
>
>                 Key: WFCORE-3458
>                 URL: https://issues.jboss.org/browse/WFCORE-3458
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 4.0.0.Alpha4
>            Reporter: Ilia Vassilev
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 	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.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> 	at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> 	... 5 more
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 	at java.nio.file.Files.newByteChannel(Files.java:361)
> 	at java.nio.file.Files.newByteChannel(Files.java:407)
> 	at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> 	at java.nio.file.Files.newInputStream(Files.java:152)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> 	... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
>     Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
>     Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
>     private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
>         KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
>         keyStore = getKeyStoreInstance("JCEKS");
>         externalStorage = new ExternalStorage();
>         try {
>             final char[] storePassword = getStorePassword(protectionParameter);
>             if (keyContainingKeyStoreLocation != null) {
>                 try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
>                     keyContainingKeyStore.load(is, storePassword);
>                 }
>             } else {
>                 // keystore without file (e.g. PKCS11)
>                 synchronized (EmptyProvider.getInstance()) {
>                     keyContainingKeyStore.load(null, storePassword);
>                 }
>             }
>             externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
>         } catch(IOException | GeneralSecurityException e) {
>             throw log.cannotInitializeCredentialStore(e);
>         }
>     }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 11:13:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Wed, 13 Dec 2017 11:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3459) External CS,
 PKCS11 can't be configured with externalPath
In-Reply-To: <JIRA.12724716.1513181555000@Atlassian.JIRA>
References: <JIRA.12724716.1513181555000@Atlassian.JIRA>
	<JIRA.12724716.1513181555400@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724716.1513181555000.118205.1513181580687@Atlassian.JIRA>

Ilia Vassilev created WFCORE-3459:
-------------------------------------

             Summary: External CS, PKCS11 can't be configured with externalPath 
                 Key: WFCORE-3459
                 URL: https://issues.jboss.org/browse/WFCORE-3459
             Project: WildFly Core
          Issue Type: Bug
          Components: Security
    Affects Versions: 4.0.0.Alpha4
            Reporter: Ilia Vassilev
            Assignee: Ilia Vassilev
            Priority: Critical


To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.

{code}
10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
	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.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
	at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
	... 5 more
Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
	at java.nio.file.Files.newByteChannel(Files.java:361)
	at java.nio.file.Files.newByteChannel(Files.java:407)
	at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
	at java.nio.file.Files.newInputStream(Files.java:152)
	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
	... 9 more

10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("credential-store" => "fips-credential-store")
]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
    Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
    Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
{code}

Problem seems to be in method
{code:java|title=KeyStoreCredentialStore.java}
    private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
        KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
        keyStore = getKeyStoreInstance("JCEKS");
        externalStorage = new ExternalStorage();
        try {
            final char[] storePassword = getStorePassword(protectionParameter);
            if (keyContainingKeyStoreLocation != null) {
                try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
                    keyContainingKeyStore.load(is, storePassword);
                }
            } else {
                // keystore without file (e.g. PKCS11)
                synchronized (EmptyProvider.getInstance()) {
                    keyContainingKeyStore.load(null, storePassword);
                }
            }
            externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
        } catch(IOException | GeneralSecurityException e) {
            throw log.cannotInitializeCredentialStore(e);
        }
    }
{code}

Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 11:26:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Wed, 13 Dec 2017 11:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3458) External CS,
 PKCS11 can't be configured with externalPath
In-Reply-To: <JIRA.12724714.1513181174000@Atlassian.JIRA>
References: <JIRA.12724714.1513181174000@Atlassian.JIRA>
	<JIRA.12724714.1513181174000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724714.1513181174000.118347.1513182360758@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505087#comment-13505087 ] 

Ilia Vassilev commented on WFCORE-3458:
---------------------------------------

In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"


> External CS, PKCS11 can't be configured with externalPath 
> ----------------------------------------------------------
>
>                 Key: WFCORE-3458
>                 URL: https://issues.jboss.org/browse/WFCORE-3458
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 4.0.0.Alpha4
>            Reporter: Ilia Vassilev
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 	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.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> 	at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> 	... 5 more
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 	at java.nio.file.Files.newByteChannel(Files.java:361)
> 	at java.nio.file.Files.newByteChannel(Files.java:407)
> 	at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> 	at java.nio.file.Files.newInputStream(Files.java:152)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> 	... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
>     Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
>     Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
>     private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
>         KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
>         keyStore = getKeyStoreInstance("JCEKS");
>         externalStorage = new ExternalStorage();
>         try {
>             final char[] storePassword = getStorePassword(protectionParameter);
>             if (keyContainingKeyStoreLocation != null) {
>                 try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
>                     keyContainingKeyStore.load(is, storePassword);
>                 }
>             } else {
>                 // keystore without file (e.g. PKCS11)
>                 synchronized (EmptyProvider.getInstance()) {
>                     keyContainingKeyStore.load(null, storePassword);
>                 }
>             }
>             externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
>         } catch(IOException | GeneralSecurityException e) {
>             throw log.cannotInitializeCredentialStore(e);
>         }
>     }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 11:29:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 13 Dec 2017 11:29:00 -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.1513182505065@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724717.1513182505000.118390.1513182540585@Atlassian.JIRA>

Darran Lofthouse created ELY-1466:
-------------------------------------

             Summary: 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.Beta11


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  Wed Dec 13 11:48:00 2017
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 13 Dec 2017 11:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3460) Update the public packages
 in the org.wildfly.security.elytron module
In-Reply-To: <JIRA.12724719.1513183626000@Atlassian.JIRA>
References: <JIRA.12724719.1513183626000@Atlassian.JIRA>
	<JIRA.12724719.1513183626295@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724719.1513183626000.118529.1513183680936@Atlassian.JIRA>

Farah Juma created WFCORE-3460:
----------------------------------

             Summary: Update the public packages in the org.wildfly.security.elytron module
                 Key: WFCORE-3460
                 URL: https://issues.jboss.org/browse/WFCORE-3460
             Project: WildFly Core
          Issue Type: Task
          Components: Security
            Reporter: Farah Juma
            Assignee: Farah Juma


ELY-1451 is going to make the {{org.wildfly.security.asn1}}, {{org.wildfly.security.x500}}, and {{org.wildfly.security.x500.cert}} pacakges public. The Elytron module definition needs to be updated to reflect this.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 14:08:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 13 Dec 2017 14:08:00 -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.59.1513192080143@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505219#comment-13505219 ] 

Martin Choma commented on ELY-1466:
-----------------------------------

What about other mechanism combination? Does it not apply to those? What about DIGEST?

> 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.Beta11
>
>
> 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  Wed Dec 13 14:51:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 13 Dec 2017 14:51: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.178.1513194660190@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502673#comment-13502673 ] 

Jan Kalina edited comment on ELY-283 at 12/13/17 2:50 PM:
----------------------------------------------------------

Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...

{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/-1696122173
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
    Calling Error = 0
    Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
    Supplementary Status Bits = 0
minor = -1696122173 (signed dec) = 2598845123 (unsigned dec) =  9AE73AC3 (hex)
{code}
*Update:* the error above occure when ccache does not exists - to resolve, run *kinit* and sign in as any unrelated user - even from unrelated kerberos realm - when the ccache exists, *remote/localhost at JBOSS.ORG* credential is obtained correctly too. (After kdestroy the error above will return.)


was (Author: honza889):
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...

{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/-1696122173
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
    Calling Error = 0
    Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
    Supplementary Status Bits = 0
minor = -1696122173 (signed dec) = 2598845123 (unsigned dec) =  9AE73AC3 (hex)
{code}

> 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
>
>
> 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 Dec 13 14:58:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 13 Dec 2017 14:58:00 -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.183.1513195080198@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505231#comment-13505231 ] 

David Lloyd commented on ELY-1466:
----------------------------------

Have a look at [RFC 8053|https://tools.ietf.org/html/rfc8053] which describes some behaviors of optional authentication.

> 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.Beta11
>
>
> 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  Wed Dec 13 16:07:00 2017
From: issues at jboss.org (Ray Ramos (JIRA))
Date: Wed, 13 Dec 2017 16:07:00 -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.443.1513199220198@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505258#comment-13505258 ] 

Ray Ramos commented on ELY-1466:
--------------------------------

The business requirement would be, "As an application developer, I need multiple authentication and authorizations methods configured for the same application, in order to support both human and machine consumption."

For humans, HTML, CSS, JSP, JSF, etc would be secured using FORM authentication and probably some type of SSO like LDAP or SAML.

And in the same application, a JAX-RS, JAX-WS, and possibly bare Servlet, would be configured for consumption by a machine.  This could simply be HTTP BASIC or also LDAP or SAML.

The point is, one application, multiple clients.

> 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.Beta11
>
>
> 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  Wed Dec 13 16:10:00 2017
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 13 Dec 2017 16:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6464) JPA 2.2 Support
In-Reply-To: <JIRA.12612939.1459635658000@Atlassian.JIRA>
References: <JIRA.12612939.1459635658000@Atlassian.JIRA>
	<JIRA.12612939.1459635658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12612939.1459635658000.450.1513199400258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-6464:
-------------------------------
    Description: 
>From JPA 2.2 specification appendix section A.1:
{code}
A.1 Maintenance Release Draft

Created document from Java Persistence 2.1 Final Release specification.

The following annotations have been marked @Repeatable:
 AssociationOverride
 AttributeOverride
 Convert
 JoinColumn
 MapKeyJoinColumn
 NamedEntityGraph
 NamedNativeQuery 
 NamedQuery
 NamedStoredProcedureQuery
 PersistenceContext
 PersistenceUnit
 PrimaryKeyJoinColumn
 SecondaryTable
 SqlResultSetMapping
 SequenceGenerator
 TableGenerator

Added SequenceGenerators and TableGenerators annotations.

Added support for CDI injection into AttributeConverter classes.

Added support for the mapping of the following java.time types:
 java.time.LocalDate
 java.time.LocalTime
 java.time.LocalDateTime
 java.time.OffsetTime
 java.time.OffsetDateTime

Added default Stream getResultStream() method to Query interface.

Added default Stream<X> getResultStream() method to TypedQuery interface.

Replaced reference to JAR file specification in persistence provider bootstrapping section with more general reference to Java SE service provider requirements.

Updated persistence.xml and orm.xml schemas to 2.2 versions.

Updated Related Documents.
{code}

  was:
>From JPA 2.2 specification appendix section A.1:
{code}
A.1 Maintenance Release Draft

Created document from Java Persistence 2.1 Final Release specification.

The following annotations have been marked @Repeatable:
 AssociationOverride
 AttributeOverride
 Convert
 JoinColumn
 MapKeyJoinColumn
 NamedEntityGraph
 NamedNativeQuery 
 NamedQuery
 NamedStoredProcedureQuery
 PersistenceContext
 PersistenceUnit
 PrimaryKeyJoinColumn
 SecondaryTable
 SqlResultSetMapping
 SequenceGenerator
 TableGenerator

Added SequenceGenerators and TableGenerators annotations.

Added support for CDI injection into AttributeConverter classes.

Added support for the mapping of the following java.time types:
 java.time.LocalDate
 java.time.LocalTime
 java.time.LocalDateTime
 java.time.OffsetTime
 java.time.OffsetDateTime

Added default Stream getResultStream() method to Query interface.

Added default Stream<X> getResultStream() method to TypedQuery interface.

Replaced reference to JAR file specification in persistence provider bootstrapping section with more

general reference to Java SE service provider requirements.

Updated persistence.xml and orm.xml schemas to 2.2 versions.

Updated Related Documents.
{code}



> JPA 2.2 Support
> ---------------
>
>                 Key: WFLY-6464
>                 URL: https://issues.jboss.org/browse/WFLY-6464
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 12.0.0.Alpha1
>
>
> From JPA 2.2 specification appendix section A.1:
> {code}
> A.1 Maintenance Release Draft
> Created document from Java Persistence 2.1 Final Release specification.
> The following annotations have been marked @Repeatable:
>  AssociationOverride
>  AttributeOverride
>  Convert
>  JoinColumn
>  MapKeyJoinColumn
>  NamedEntityGraph
>  NamedNativeQuery 
>  NamedQuery
>  NamedStoredProcedureQuery
>  PersistenceContext
>  PersistenceUnit
>  PrimaryKeyJoinColumn
>  SecondaryTable
>  SqlResultSetMapping
>  SequenceGenerator
>  TableGenerator
> Added SequenceGenerators and TableGenerators annotations.
> Added support for CDI injection into AttributeConverter classes.
> Added support for the mapping of the following java.time types:
>  java.time.LocalDate
>  java.time.LocalTime
>  java.time.LocalDateTime
>  java.time.OffsetTime
>  java.time.OffsetDateTime
> Added default Stream getResultStream() method to Query interface.
> Added default Stream<X> getResultStream() method to TypedQuery interface.
> Replaced reference to JAR file specification in persistence provider bootstrapping section with more general reference to Java SE service provider requirements.
> Updated persistence.xml and orm.xml schemas to 2.2 versions.
> Updated Related Documents.
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 16:33:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 13 Dec 2017 16:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2131) [DMN Editor] Boxed
 Expressions: Invocation editor
In-Reply-To: <JIRA.12720913.1510651966000@Atlassian.JIRA>
References: <JIRA.12720913.1510651966000@Atlassian.JIRA>
	<JIRA.12720913.1510651966000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720913.1510651966000.552.1513200780125@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505267#comment-13505267 ] 

Michael Anstis commented on DROOLS-2131:
----------------------------------------

See https://github.com/manstis/kie-wb-common/commit/f65906acad1f3841ad754f5600a7cc198eac9e35

> [DMN Editor] Boxed Expressions: Invocation editor
> -------------------------------------------------
>
>                 Key: DROOLS-2131
>                 URL: https://issues.jboss.org/browse/DROOLS-2131
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 16:33:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 13 Dec 2017 16:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2131) [DMN Editor] Boxed
 Expressions: Invocation editor
In-Reply-To: <JIRA.12720913.1510651966000@Atlassian.JIRA>
References: <JIRA.12720913.1510651966000@Atlassian.JIRA>
	<JIRA.12720913.1510651966000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720913.1510651966000.554.1513200780167@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis resolved DROOLS-2131.
------------------------------------
    Resolution: Done


> [DMN Editor] Boxed Expressions: Invocation editor
> -------------------------------------------------
>
>                 Key: DROOLS-2131
>                 URL: https://issues.jboss.org/browse/DROOLS-2131
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 13 17:04:00 2017
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Wed, 13 Dec 2017 17:04: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.732.1513202640407@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505279#comment-13505279 ] 

Scott Van Wart commented on WFLY-9529:
--------------------------------------

[~emmartins] does the startup delay you put in injected-jms2.zip work around this issue?  I'm at the point where I'll need to just start using an injected ConnectionFactory and manage my own JMSContext objects. I've noticed that it doesn't happen all the time (but sometimes will happen consistently--as in the original project I attached).

> 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  Wed Dec 13 18:33:00 2017
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Wed, 13 Dec 2017 18:33: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.1327.1513207980276@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505308#comment-13505308 ] 

Eduardo Martins commented on WFLY-9529:
---------------------------------------

[~silvaran] No, that was just a simplification of the app, the issue is that on such event, and without a EE component in context, the Java EE standard JNDI contexts are not available, and JMSContext dependency on it makes it fail to work. There are two possible solutions for this, make such contexts (even if limited on resources bound) available, or instead remove usage of JNDI by the injected JMSContext implementation, and while I can code both quickly I'm investigating what is the proper solution (even comparing with other vendor app servers).

By the way, I did not test that but it should work if you pack the app in a war instead of ear.

> 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  Wed Dec 13 19:51:00 2017
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Wed, 13 Dec 2017 19:51: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.1392.1513212660471@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505320#comment-13505320 ] 

Scott Van Wart commented on WFLY-9529:
--------------------------------------

[~emmartins] I'm under the impression that when a managed thread is produced or a task is submitted to the scheduler service, it's created in such a way that it can never look up that TransactionSynchronizationRegistry.  Sometimes it works and sometimes it doesn't--and if it doesn't, the problem persists until Wildfly is restarted. Is it a race condition (e.g. a CDI bean making use of a resource before the EE components are fully booted)?  Would it help if I only use @Resource ManagedExecutorService or @Resource ManagedThreadFactory from within EJBs--and not from within CDI beans?

For what it's worth, your second solution gets my vote as it seems like the @Inject JMSContext is the only component exhibiting this behavour.  Thanks so much for the information.

> 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  Wed Dec 13 19:51:00 2017
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Wed, 13 Dec 2017 19:51: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.1398.1513212660640@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505320#comment-13505320 ] 

Scott Van Wart edited comment on WFLY-9529 at 12/13/17 7:50 PM:
----------------------------------------------------------------

[~emmartins] I'm under the impression that when a managed thread is produced or a task is submitted to the scheduler service, it's created in such a way that it can never look up that TransactionSynchronizationRegistry.  Sometimes it works and sometimes it doesn't. If it doesn't, the problem persists until Wildfly is restarted. Is it a race condition (e.g. a CDI bean making use of a resource before the EE components are fully booted)?  Would it help if I only use @Resource ManagedExecutorService or @Resource ManagedThreadFactory from within EJBs--and not from within CDI beans?

For what it's worth, your second solution gets my vote as it seems like the @Inject JMSContext is the only component exhibiting this behavour.  Thanks so much for the information.


was (Author: silvaran):
[~emmartins] I'm under the impression that when a managed thread is produced or a task is submitted to the scheduler service, it's created in such a way that it can never look up that TransactionSynchronizationRegistry.  Sometimes it works and sometimes it doesn't--and if it doesn't, the problem persists until Wildfly is restarted. Is it a race condition (e.g. a CDI bean making use of a resource before the EE components are fully booted)?  Would it help if I only use @Resource ManagedExecutorService or @Resource ManagedThreadFactory from within EJBs--and not from within CDI beans?

For what it's worth, your second solution gets my vote as it seems like the @Inject JMSContext is the only component exhibiting this behavour.  Thanks so much for the information.

> 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  Thu Dec 14 04:02:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 14 Dec 2017 04:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2237) The single node in the
 cluster not become a coordinator after coordinator leave.
In-Reply-To: <JIRA.12722542.1511866861000@Atlassian.JIRA>
References: <JIRA.12722542.1511866861000@Atlassian.JIRA>
	<JIRA.12722542.1511866861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722542.1511866861000.2215.1513242120296@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505365#comment-13505365 ] 

Bela Ban commented on JGRP-2237:
--------------------------------

I wrote a simple program which continually disconnects and then reconnects the coordinator (bla3, attached). I ran it for over a 1000 disconnect/reconnect sequences and it never failed.
Run it yourself (change the path to the properties), to see if it fails.
{noformat}
-------------------------------------------------------------------
GMS: address=A, cluster=demo, physical address=127.0.0.1:7800
-------------------------------------------------------------------
-- view: [B|1071] (2) [B, A]
-- view: [A|1072] (1) [A]
-- view: [A|1073] (2) [A, B]
{noformat}


> The single node in the cluster not become a coordinator after coordinator leave.
> --------------------------------------------------------------------------------
>
>                 Key: JGRP-2237
>                 URL: https://issues.jboss.org/browse/JGRP-2237
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.2, 4.0.8
>            Reporter: kfir avraham
>            Assignee: Bela Ban
>            Priority: Minor
>         Attachments: Server_A.txt, Server_A_Trace_mode.rtf, Server_B.txt, Server_B_Trace_mode.rtf, conf.txt, test.xml
>
>
> I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator.
> When the first one is rejoin, he could not determine coordinator and select new one from the nodes list.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 04:03:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 14 Dec 2017 04:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2237) The single node in the
 cluster not become a coordinator after coordinator leave.
In-Reply-To: <JIRA.12722542.1511866861000@Atlassian.JIRA>
References: <JIRA.12722542.1511866861000@Atlassian.JIRA>
	<JIRA.12722542.1511866861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722542.1511866861000.2220.1513242180199@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2237:
---------------------------
    Attachment: bla3.java


> The single node in the cluster not become a coordinator after coordinator leave.
> --------------------------------------------------------------------------------
>
>                 Key: JGRP-2237
>                 URL: https://issues.jboss.org/browse/JGRP-2237
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.2, 4.0.8
>            Reporter: kfir avraham
>            Assignee: Bela Ban
>            Priority: Minor
>         Attachments: Server_A.txt, Server_A_Trace_mode.rtf, Server_B.txt, Server_B_Trace_mode.rtf, bla3.java, conf.txt, test.xml
>
>
> I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator.
> When the first one is rejoin, he could not determine coordinator and select new one from the nodes list.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 05:13:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 14 Dec 2017 05:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1213) Remove match-purpose from
	Elytron
In-Reply-To: <JIRA.12695018.1496226662000@Atlassian.JIRA>
References: <JIRA.12695018.1496226662000@Atlassian.JIRA>
	<JIRA.12695018.1496226662000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12695018.1496226662000.2734.1513246380725@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-1213.
---------------------------


> Remove match-purpose from Elytron
> ---------------------------------
>
>                 Key: ELY-1213
>                 URL: https://issues.jboss.org/browse/ELY-1213
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta47
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 1.1.0.Beta51
>
>
> Match purpose should be entirely removed, see [1]. It means it should be removed from API, Elytron subsystem and Elytron client configuration file.
> We request blocker flag to avoid situation where match-purpose occurs in GA.
> [1] https://issues.jboss.org/browse/JBEAP-11144?focusedCommentId=13413867&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13413867



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 05:14:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 14 Dec 2017 05:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1064) Deprecate "purpose" match
 criteria and parameter
In-Reply-To: <JIRA.12686508.1491505859000@Atlassian.JIRA>
References: <JIRA.12686508.1491505859000@Atlassian.JIRA>
	<JIRA.12686508.1491505859000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12686508.1491505859000.2742.1513246440397@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-1064.
---------------------------


> Deprecate "purpose" match criteria and parameter
> ------------------------------------------------
>
>                 Key: ELY-1064
>                 URL: https://issues.jboss.org/browse/ELY-1064
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>            Reporter: David Lloyd
>             Fix For: 1.1.0.Beta51
>
>
> The "purpose" property was a mistake; it will not be used by any of the Elytron-aware client libraries.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 05:15:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 14 Dec 2017 05:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1119) Setting
 sasl-mechanism-selector with some name value in Elytron client
 configuration file causes NPE during parsing
In-Reply-To: <JIRA.12690173.1493724648000@Atlassian.JIRA>
References: <JIRA.12690173.1493724648000@Atlassian.JIRA>
	<JIRA.12690173.1493724648000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12690173.1493724648000.2748.1513246500455@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-1119.
---------------------------


> Setting sasl-mechanism-selector with some name value in Elytron client configuration file causes NPE during parsing
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-1119
>                 URL: https://issues.jboss.org/browse/ELY-1119
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>    Affects Versions: 1.1.0.Beta39
>            Reporter: Ondrej Lukas
>            Priority: Critical
>             Fix For: 1.1.0.Beta41
>
>
> In case when sasl-mechanism-selector is set in Elytron client configuration file then parsing of configuration file throws NPE. For following element (since there is no documentation then I tried to use values "someName", "NONE", "PLAIN" instead of someName):
> {code}
> <sasl-mechanism-selector selector="someName"/>
> {code}
> is following NPE thrown:
> {code}
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /dep/authenticationContext: java.lang.NullPointerException
> 	at org.wildfly.security.sasl.SaslMechanismSelector$AddSelector.addHashCode(SaslMechanismSelector.java:768)
> 	at org.wildfly.security.sasl.SaslMechanismSelector.hashCode(SaslMechanismSelector.java:177)
> 	at org.wildfly.security.sasl.SaslMechanismSelector.equals(SaslMechanismSelector.java:188)
> 	at org.wildfly.security.sasl.SaslMechanismSelector.equals(SaslMechanismSelector.java:184)
> 	at java.util.Objects.equals(Objects.java:59)
> 	at org.wildfly.security.auth.client.AuthenticationConfiguration.setSaslMechanismSelector(AuthenticationConfiguration.java:1037)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$18(ElytronXmlParser.java:640)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$25(ElytronXmlParser.java:704)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$7(ElytronXmlParser.java:513)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:537)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:308)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:180)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:141)
> 	at com.redhat.eap.qe.elytron.authnctx.WildflyConfigXmlServlet.parseAndCreateAuthenticationClientConfiguration(WildflyConfigXmlServlet.java:116)
> 	at com.redhat.eap.qe.elytron.authnctx.WildflyConfigXmlServlet.doGet(WildflyConfigXmlServlet.java:91)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	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:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	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.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 	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:211)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> 	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)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 05:17:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 14 Dec 2017 05:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-855) Add ability to merge
 AuthenticationConfigurations
In-Reply-To: <JIRA.12668592.1482336049000@Atlassian.JIRA>
References: <JIRA.12668592.1482336049000@Atlassian.JIRA>
	<JIRA.12668592.1482336049000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668592.1482336049000.2754.1513246620308@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461801#comment-13461801 ] 

Jan Kalina edited comment on ELY-855 at 12/14/17 5:16 AM:
----------------------------------------------------------

This is already implemented: https://github.com/wildfly-security/wildfly-elytron/commit/2c30498801dd2a6404d74a1cb7948ec8bed36f69#diff-c326ff349cb9d8a1a54a2f94e9e3683aR1081


was (Author: honza889):
This is already implemented: https://github.com/wildfly-security/wildfly-elytron/blame/master/src/main/java/org/wildfly/security/auth/client/AuthenticationConfiguration.java#L1224

> Add ability to merge AuthenticationConfigurations
> -------------------------------------------------
>
>                 Key: ELY-855
>                 URL: https://issues.jboss.org/browse/ELY-855
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Beta29
>
>
> We need a "with" method on AuthenticationConfiguration which appends one configuration to another.  This allows for fallback defaults.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 05:17:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 05:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2177) [DMN Editor]
 EditableHeaderMetaData should destroy resources
In-Reply-To: <JIRA.12724887.1513246602000@Atlassian.JIRA>
References: <JIRA.12724887.1513246602000@Atlassian.JIRA>
	<JIRA.12724887.1513246602960@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724887.1513246602000.2756.1513246620401@Atlassian.JIRA>

Michael Anstis created DROOLS-2177:
--------------------------------------

             Summary: [DMN Editor] EditableHeaderMetaData should destroy resources
                 Key: DROOLS-2177
                 URL: https://issues.jboss.org/browse/DROOLS-2177
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
            Reporter: Michael Anstis
            Assignee: Michael Anstis


{{EditableHeaderMetaData}} Uses {{DOMElementFactory}} for {{DOMElement}} used to edit the header's content. If the User starts editing a column header and then performs some action (such as resizing a column, panning, etc) the {{DOMElement}} is not destroyed.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 05:17:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 14 Dec 2017 05:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-855) Add ability to merge
 AuthenticationConfigurations
In-Reply-To: <JIRA.12668592.1482336049000@Atlassian.JIRA>
References: <JIRA.12668592.1482336049000@Atlassian.JIRA>
	<JIRA.12668592.1482336049000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668592.1482336049000.2759.1513246620484@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-855.
--------------------------


> Add ability to merge AuthenticationConfigurations
> -------------------------------------------------
>
>                 Key: ELY-855
>                 URL: https://issues.jboss.org/browse/ELY-855
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Beta29
>
>
> We need a "with" method on AuthenticationConfiguration which appends one configuration to another.  This allows for fallback defaults.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 05:29:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 14 Dec 2017 05:29: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.2857.1513247340373@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502673#comment-13502673 ] 

Jan Kalina edited comment on ELY-283 at 12/14/17 5:28 AM:
----------------------------------------------------------

Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...

{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/-1696122173
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
    Calling Error = 0
    Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
    Supplementary Status Bits = 0
minor = -1696122173 (signed dec) = 2598845123 (unsigned dec) =  9AE73AC3 (hex)
{code}
*Update:* the error above occure when ccache does not exists - to resolve, run *kinit* and sign in as any unrelated user - even from unrelated kerberos realm - when the ccache exists, *remote/localhost at JBOSS.ORG* credential is obtained correctly too. (After kdestroy the error above will return.)
*Update:* from discussion with Simo Sorce (gssproxy dev) results this is *bug of gssproxy*. For our purpose workaround by creating ccache using unrelated *kinit* is sufficient - we dont need to wait for fix for wildfly development (but it can be important for production).


was (Author: honza889):
Currently it look gssproxy is providing credential correctly (with no error - major=0, minor=0 - by debug of gssproxy), but into java GSSContext arrive GSS_S_FAILURE - looks like raised somewhere on the way between gssproxy and JDK - have to investigate deeper...

{code}
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=140518513672464, usage=2
[GSSLibStub_acquireCred] pCred=0
[GSSLibStub_acquireCred] Status major/minor = d0000/-1696122173
c/r/s = 0/13/0
{code}
{code}
major = d0000 = 0 / 13 / 0
    Calling Error = 0
    Routine Error = 13 = GSS_S_FAILURE = Miscellaneous failure (see text)
    Supplementary Status Bits = 0
minor = -1696122173 (signed dec) = 2598845123 (unsigned dec) =  9AE73AC3 (hex)
{code}
*Update:* the error above occure when ccache does not exists - to resolve, run *kinit* and sign in as any unrelated user - even from unrelated kerberos realm - when the ccache exists, *remote/localhost at JBOSS.ORG* credential is obtained correctly too. (After kdestroy the error above will return.)

> 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
>
>
> 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 Dec 14 05:38:00 2017
From: issues at jboss.org (Serg Pol (JIRA))
Date: Thu, 14 Dec 2017 05:38: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.2883.1513247880662@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505403#comment-13505403 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

Batch Jobs have just values for BATCHSTATUS = "STARTING" (no Status STARTED. i could not reproduce STATUS "STARTING" local) and CREATETIME in this case-issue.

Thread pool has max number of threads 10 (<max-threads count="10"/>)
In what case BATCHSTATUS can be left just "STARTING"? If there were no enough threads?
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  Thu Dec 14 05:55:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 05:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2177) [DMN Editor]
 EditableHeaderMetaData should destroy resources
In-Reply-To: <JIRA.12724887.1513246603000@Atlassian.JIRA>
References: <JIRA.12724887.1513246603000@Atlassian.JIRA>
	<JIRA.12724887.1513246603000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724887.1513246603000.2959.1513248900247@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2177:
-----------------------------------
    Tester: Jozef Marko


> [DMN Editor] EditableHeaderMetaData should destroy resources
> ------------------------------------------------------------
>
>                 Key: DROOLS-2177
>                 URL: https://issues.jboss.org/browse/DROOLS-2177
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> {{EditableHeaderMetaData}} Uses {{DOMElementFactory}} for {{DOMElement}} used to edit the header's content. If the User starts editing a column header and then performs some action (such as resizing a column, panning, etc) the {{DOMElement}} is not destroyed.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 05:56:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 05:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2177) [DMN Editor]
 EditableHeaderMetaData should destroy resources
In-Reply-To: <JIRA.12724887.1513246603000@Atlassian.JIRA>
References: <JIRA.12724887.1513246603000@Atlassian.JIRA>
	<JIRA.12724887.1513246603000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724887.1513246603000.2967.1513248960174@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505407#comment-13505407 ] 

Michael Anstis commented on DROOLS-2177:
----------------------------------------

See https://github.com/manstis/kie-wb-common/commit/0ce629e02f901109f8eee0cdbe5e834d2a786eee

> [DMN Editor] EditableHeaderMetaData should destroy resources
> ------------------------------------------------------------
>
>                 Key: DROOLS-2177
>                 URL: https://issues.jboss.org/browse/DROOLS-2177
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> {{EditableHeaderMetaData}} Uses {{DOMElementFactory}} for {{DOMElement}} used to edit the header's content. If the User starts editing a column header and then performs some action (such as resizing a column, panning, etc) the {{DOMElement}} is not destroyed.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 05:56:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 05:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2177) [DMN Editor]
 EditableHeaderMetaData should destroy resources
In-Reply-To: <JIRA.12724887.1513246603000@Atlassian.JIRA>
References: <JIRA.12724887.1513246603000@Atlassian.JIRA>
	<JIRA.12724887.1513246603000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724887.1513246603000.2969.1513248960265@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis resolved DROOLS-2177.
------------------------------------
    Resolution: Done


> [DMN Editor] EditableHeaderMetaData should destroy resources
> ------------------------------------------------------------
>
>                 Key: DROOLS-2177
>                 URL: https://issues.jboss.org/browse/DROOLS-2177
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> {{EditableHeaderMetaData}} Uses {{DOMElementFactory}} for {{DOMElement}} used to edit the header's content. If the User starts editing a column header and then performs some action (such as resizing a column, panning, etc) the {{DOMElement}} is not destroyed.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 06:06:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 06:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2178) [DMN Editor] Simplify
 Expression Editors GridData implementation
In-Reply-To: <JIRA.12724893.1513249516000@Atlassian.JIRA>
References: <JIRA.12724893.1513249516000@Atlassian.JIRA>
	<JIRA.12724893.1513249516211@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724893.1513249516000.3039.1513249560136@Atlassian.JIRA>

Michael Anstis created DROOLS-2178:
--------------------------------------

             Summary: [DMN Editor] Simplify Expression Editors GridData implementation
                 Key: DROOLS-2178
                 URL: https://issues.jboss.org/browse/DROOLS-2178
             Project: Drools
          Issue Type: Task
          Components: DMN Editor
            Reporter: Michael Anstis
            Assignee: Michael Anstis


Different Expression Editors implement their own {{GridData}} models to intercept mutations and defer the same to Commands. There are a number of different implementations and they could all be simplified to use a shared base class.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 06:09:00 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 14 Dec 2017 06:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2178) [DMN Editor] Simplify
 Expression Editors GridData implementation
In-Reply-To: <JIRA.12724893.1513249516000@Atlassian.JIRA>
References: <JIRA.12724893.1513249516000@Atlassian.JIRA>
	<JIRA.12724893.1513249516000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724893.1513249516000.3051.1513249740099@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2178:
--------------------------------
       Tester: Jozef Marko
    QE Status: ON_QA  (was: NEW)


> [DMN Editor] Simplify Expression Editors GridData implementation
> ----------------------------------------------------------------
>
>                 Key: DROOLS-2178
>                 URL: https://issues.jboss.org/browse/DROOLS-2178
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Different Expression Editors implement their own {{GridData}} models to intercept mutations and defer the same to Commands. There are a number of different implementations and they could all be simplified to use a shared base class.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 06:21:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 06:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2178) [DMN Editor] Simplify
 Expression Editors GridData implementation
In-Reply-To: <JIRA.12724893.1513249516000@Atlassian.JIRA>
References: <JIRA.12724893.1513249516000@Atlassian.JIRA>
	<JIRA.12724893.1513249516000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724893.1513249516000.3112.1513250460613@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505419#comment-13505419 ] 

Michael Anstis commented on DROOLS-2178:
----------------------------------------

See https://github.com/manstis/kie-wb-common/commit/0bb44bd3d78df2f559172f01ff5db092ef8c36d2

> [DMN Editor] Simplify Expression Editors GridData implementation
> ----------------------------------------------------------------
>
>                 Key: DROOLS-2178
>                 URL: https://issues.jboss.org/browse/DROOLS-2178
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Different Expression Editors implement their own {{GridData}} models to intercept mutations and defer the same to Commands. There are a number of different implementations and they could all be simplified to use a shared base class.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 06:21:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 06:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2178) [DMN Editor] Simplify
 Expression Editors GridData implementation
In-Reply-To: <JIRA.12724893.1513249516000@Atlassian.JIRA>
References: <JIRA.12724893.1513249516000@Atlassian.JIRA>
	<JIRA.12724893.1513249516000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724893.1513249516000.3121.1513250460890@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis resolved DROOLS-2178.
------------------------------------
    Resolution: Done


> [DMN Editor] Simplify Expression Editors GridData implementation
> ----------------------------------------------------------------
>
>                 Key: DROOLS-2178
>                 URL: https://issues.jboss.org/browse/DROOLS-2178
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Different Expression Editors implement their own {{GridData}} models to intercept mutations and defer the same to Commands. There are a number of different implementations and they could all be simplified to use a shared base class.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 06:28:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 06:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2179) [DMN Editor]
 EditableHeaderMetaData DOMElement can span multiple columns
In-Reply-To: <JIRA.12724895.1513250819000@Atlassian.JIRA>
References: <JIRA.12724895.1513250819000@Atlassian.JIRA>
	<JIRA.12724895.1513250819986@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724895.1513250819000.3144.1513250880174@Atlassian.JIRA>

Michael Anstis created DROOLS-2179:
--------------------------------------

             Summary: [DMN Editor] EditableHeaderMetaData DOMElement can span multiple columns
                 Key: DROOLS-2179
                 URL: https://issues.jboss.org/browse/DROOLS-2179
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
            Reporter: Michael Anstis
            Assignee: Michael Anstis


A {{EditableHeaderMetaData}} can span multiple columns. However when the User double-clicks to edit the header the {{DOMElement}} is sized and positioned for the single column in which the User double-clicked. It should span multiple columns if need be.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 06:28:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 06:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2179) [DMN Editor]
 EditableHeaderMetaData DOMElement can span multiple columns
In-Reply-To: <JIRA.12724895.1513250820000@Atlassian.JIRA>
References: <JIRA.12724895.1513250820000@Atlassian.JIRA>
	<JIRA.12724895.1513250820000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724895.1513250820000.3147.1513250880296@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2179:
-----------------------------------
    Tester: Jozef Marko


> [DMN Editor] EditableHeaderMetaData DOMElement can span multiple columns
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-2179
>                 URL: https://issues.jboss.org/browse/DROOLS-2179
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> A {{EditableHeaderMetaData}} can span multiple columns. However when the User double-clicks to edit the header the {{DOMElement}} is sized and positioned for the single column in which the User double-clicked. It should span multiple columns if need be.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 07:13:00 2017
From: issues at jboss.org (Serg Pol (JIRA))
Date: Thu, 14 Dec 2017 07:13: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.3407.1513253580136@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505453#comment-13505453 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

Thanks
i have reproduced case with status "STARTING" - if the configured number of threads is less as number of started Batch-Jobs


> 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  Thu Dec 14 08:04:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 14 Dec 2017 08:04:00 -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.3717.1513256640252@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505480#comment-13505480 ] 

Darran Lofthouse commented on ELY-1466:
---------------------------------------

No this would not be applicable to DIGEST, the DIGEST mechanism can not function without sending a challenge first.

> 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.Beta11
>
>
> 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 Dec 14 08:08:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 14 Dec 2017 08:08:00 -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.1513256838340@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724916.1513256838000.3724.1513256880286@Atlassian.JIRA>

Darran Lofthouse created ELY-1467:
-------------------------------------

             Summary: 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.Beta11






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 08:08:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 14 Dec 2017 08:08:00 -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.3728.1513256880454@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1467:
----------------------------------
    Description: https://tools.ietf.org/html/rfc8053


> 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.Beta11
>
>
> https://tools.ietf.org/html/rfc8053



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 08:10:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 14 Dec 2017 08:10:00 -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.3736.1513257000464@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505482#comment-13505482 ] 

Darran Lofthouse commented on ELY-1466:
---------------------------------------

I have created the following to track the optional authentication RFC, I think that is slightly different to the request here https://issues.jboss.org/browse/ELY-1467

For more complex scenarios we could even consider user agent filtering.

> 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.Beta11
>
>
> 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 Dec 14 08:12:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 14 Dec 2017 08:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1468) IBM java,
 403 instead of 401 sent, when kerberos mechanism is not supported
In-Reply-To: <JIRA.12724918.1513257108000@Atlassian.JIRA>
References: <JIRA.12724918.1513257108000@Atlassian.JIRA>
	<JIRA.12724918.1513257108659@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724918.1513257108000.3745.1513257120392@Atlassian.JIRA>

Martin Choma created ELY-1468:
---------------------------------

             Summary: IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported
                 Key: ELY-1468
                 URL: https://issues.jboss.org/browse/ELY-1468
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Authentication Mechanisms
    Affects Versions: 1.2.0.Beta10
            Reporter: Martin Choma
            Priority: Minor


When more mechanismTypes is provided but the Kerberos mechanism is not listed as the supported one then authentication should fail.

This issue was hidden by ELY-1340.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 08:13:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 14 Dec 2017 08:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1468) IBM java,
 403 instead of 401 sent, when kerberos mechanism is not supported
In-Reply-To: <JIRA.12724918.1513257109000@Atlassian.JIRA>
References: <JIRA.12724918.1513257109000@Atlassian.JIRA>
	<JIRA.12724918.1513257109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724918.1513257109000.3747.1513257180224@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1468:
------------------------------
    Steps to Reproduce: 
{code}
git clone git at gitlab.mw.lab.eng.bos.redhat.com:jbossqe-eap/tests-ldap-kerberos.git
./build-eap71.sh -Deap -Dversion.jboss.bom=7.1.0.GA -Dversion.wildfly.core=3.0.10.Final-redhat-1 -Dmaven.repo.local=/home/mchoma/workspace/eap-versions/7.1.0.CR4/jboss-eap-7.1.0.GA-maven-repository/maven-repository -Djboss.dist.zip=/home/mchoma/workspace/eap-versions/7.1.0.CR4/jboss-eap-7.1.0.CR4.zip -Dtest=SPNEGODefaultTestCase
{code}


  was:
{code}
./build-eap71.sh -Deap -Dversion.jboss.bom=7.1.0.GA -Dversion.wildfly.core=3.0.10.Final-redhat-1 -Dmaven.repo.local=/home/mchoma/workspace/eap-versions/7.1.0.CR4/jboss-eap-7.1.0.GA-maven-repository/maven-repository -Djboss.dist.zip=/home/mchoma/workspace/eap-versions/7.1.0.CR4/jboss-eap-7.1.0.CR4.zip -Dtest=SPNEGODefaultTestCase
{code}




> IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported
> ---------------------------------------------------------------------------
>
>                 Key: ELY-1468
>                 URL: https://issues.jboss.org/browse/ELY-1468
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Mechanisms
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Priority: Minor
>
> When more mechanismTypes is provided but the Kerberos mechanism is not listed as the supported one then authentication should fail.
> This issue was hidden by ELY-1340.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 08:13:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 14 Dec 2017 08:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1468) IBM java,
 403 instead of 401 sent, when kerberos mechanism is not supported
In-Reply-To: <JIRA.12724918.1513257109000@Atlassian.JIRA>
References: <JIRA.12724918.1513257109000@Atlassian.JIRA>
	<JIRA.12724918.1513257109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724918.1513257109000.3756.1513257180546@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1468:
------------------------------
    Description: 
When more mechanismTypes is provided but the Kerberos mechanism is not listed as the supported one then authentication should fail. And 401 should be returned, but 403 is on IBM java.

This issue was hidden by ELY-1340.

  was:
When more mechanismTypes is provided but the Kerberos mechanism is not listed as the supported one then authentication should fail.

This issue was hidden by ELY-1340.



> IBM java, 403 instead of 401 sent, when kerberos mechanism is not supported
> ---------------------------------------------------------------------------
>
>                 Key: ELY-1468
>                 URL: https://issues.jboss.org/browse/ELY-1468
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Mechanisms
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Priority: Minor
>
> When more mechanismTypes is provided but the Kerberos mechanism is not listed as the supported one then authentication should fail. And 401 should be returned, but 403 is on IBM java.
> This issue was hidden by ELY-1340.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 08:20:00 2017
From: issues at jboss.org (Rafael Kapp (JIRA))
Date: Thu, 14 Dec 2017 08:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4846) Unable to create vault
In-Reply-To: <JIRA.12576606.1435672495000@Atlassian.JIRA>
References: <JIRA.12576606.1435672495000@Atlassian.JIRA>
	<JIRA.12576606.1435672495000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576606.1435672495000.3779.1513257600373@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505487#comment-13505487 ] 

Rafael Kapp commented on WFLY-4846:
-----------------------------------

Maybe this helps someone. Create an Keystore with AES instead of an RSA.
{{keytool -genseckey -alias 128bitkey -keyalg aes -keysize 128 -keystore keystore.jceks -storetype jceks}}
This could help..

> Unable to create vault
> ----------------------
>
>                 Key: WFLY-4846
>                 URL: https://issues.jboss.org/browse/WFLY-4846
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 9.0.0.CR2
>            Reporter: S?ren Dierkes
>            Assignee: Darran Lofthouse
>
> I was unable to create a vault with the current release.
> The last version I've tried and which works was 8.2.0 with Java 8



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Dec 14 08:43:00 2017
From: issues at jboss.org (Guillaume Smet (JIRA))
Date: Thu, 14 Dec 2017 08:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9615) Upgrade Hibernate Validator
	to 6.0.6.Final
In-Reply-To: <JIRA.12724925.1513258949000@Atlassian.JIRA>
References: <JIRA.12724925.1513258949000@Atlassian.JIRA>
	<JIRA.12724925.1513258949124@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724925.1513258949000.3921.1513258980197@Atlassian.JIRA>

Guillaume Smet created WFLY-9615:
------------------------------------

             Summary: Upgrade Hibernate Validator to 6.0.6.Final
                 Key: WFLY-9615
                 URL: https://issues.jboss.org/browse/WFLY-9615
             Project: WildFly
          Issue Type: Component Upgrade
            Reporter: Guillaume Smet
            Assignee: Jason Greene


We would like to upgrade Hibernate Validator to 6.0.6.Final in WildFly 12.

Here is our migration guide:
https://developer.jboss.org/wiki/HibernateValidatorMigrationGuide#jive_content_id_60x

You'll notice that in 6.0.6, we have reintroduced a few APIs that we had removed in the previous versions of 6 for this WF upgrade: we had them deprecated in 5.4 then removed in 6 but as WF is still using 5.3, WF users didn't have any notice of that. That's why we decided to reintroduce them before proposing an upgrade in WildFly.

The other APIs removed were marked as experimental and have been superseded by standard features in Bean Validation 2.0 (which is part of Java EE 8).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 08:46:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 14 Dec 2017 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3435) Expose
 capability/requirements to deployments
In-Reply-To: <JIRA.12722620.1511882454000@Atlassian.JIRA>
References: <JIRA.12722620.1511882454000@Atlassian.JIRA>
	<JIRA.12722620.1511882454000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722620.1511882454000.3946.1513259160565@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned WFCORE-3435:
-----------------------------------

    Assignee: Jeff Mesnil


> Expose capability/requirements to deployments
> ---------------------------------------------
>
>                 Key: WFCORE-3435
>                 URL: https://issues.jboss.org/browse/WFCORE-3435
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>    Affects Versions: 3.0.9.Final
>            Reporter: Bob McWhirter
>            Assignee: Jeff Mesnil
>
> For WildFly Swarm, we use a fair amount of ServiceActivators in deployments.
> Moving to WF11, we have seen some of our dependencies on Service<T>, such as NamingService.SERVICE_NAME result in deprecation warnings suggesting we move to using CAPABILITY_NAME.  From within a ServiceActivator, within a deployment, this appears to not be a possibility.
> Filed per [~ctomc]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 09:03:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 14 Dec 2017 09:03:00 -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.4073.1513260180277@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505517#comment-13505517 ] 

David Lloyd commented on ELY-1466:
----------------------------------

The optional auth RFC also talks about using regular WWW-Authenticate without a 401 response.  See section 3.1 for more info.

> 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.Beta11
>
>
> 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 Dec 14 09:51:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 09:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2179) [DMN Editor]
 EditableHeaderMetaData DOMElement can span multiple columns
In-Reply-To: <JIRA.12724895.1513250820000@Atlassian.JIRA>
References: <JIRA.12724895.1513250820000@Atlassian.JIRA>
	<JIRA.12724895.1513250820000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724895.1513250820000.4300.1513263060974@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505545#comment-13505545 ] 

Michael Anstis commented on DROOLS-2179:
----------------------------------------

See https://github.com/manstis/kie-wb-common/commit/7910ab030a3c28ab2ab1e065b489478abd545350

> [DMN Editor] EditableHeaderMetaData DOMElement can span multiple columns
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-2179
>                 URL: https://issues.jboss.org/browse/DROOLS-2179
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> A {{EditableHeaderMetaData}} can span multiple columns. However when the User double-clicks to edit the header the {{DOMElement}} is sized and positioned for the single column in which the User double-clicked. It should span multiple columns if need be.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 09:51:01 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 14 Dec 2017 09:51:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2179) [DMN Editor]
 EditableHeaderMetaData DOMElement can span multiple columns
In-Reply-To: <JIRA.12724895.1513250820000@Atlassian.JIRA>
References: <JIRA.12724895.1513250820000@Atlassian.JIRA>
	<JIRA.12724895.1513250820000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724895.1513250820000.4307.1513263061211@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis resolved DROOLS-2179.
------------------------------------
    Resolution: Done


> [DMN Editor] EditableHeaderMetaData DOMElement can span multiple columns
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-2179
>                 URL: https://issues.jboss.org/browse/DROOLS-2179
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> A {{EditableHeaderMetaData}} can span multiple columns. However when the User double-clicks to edit the header the {{DOMElement}} is sized and positioned for the single column in which the User double-clicked. It should span multiple columns if need be.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 11:08:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 14 Dec 2017 11:08: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.4771.1513267680540@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505594#comment-13505594 ] 

Jan Kalina commented on ELY-283:
--------------------------------

Problem above was resolved, but currently there is JDK bug which looks currently prevents to use native GSS:

In a lot of places in JDK there is *SunNativeProvider.INSTANCE* used, but it is initialized incorrectly - before list of supported GSS mechs is generated, so using this instance will raise exception - not existing mechanism:

{code}
GSSException: Provider SunNativeGSS does not support mechanism 1.2.840.113554.1.2.2
    at java.security.jgss/sun.security.jgss.ProviderList.getMechFactory(ProviderList.java:253)
    at java.security.jgss/sun.security.jgss.ProviderList.getMechFactory(ProviderList.java:209)
    at java.security.jgss/sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:234)
    at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:337)
    at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:302)
{code}
It would be sufficient to change order of SunNativeProvider initializers, but it needs JDK patch.

Reported to security-dev at openjdk.java.net list and will try to find workaround without JDK modification...

> 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
>
>
> 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 Dec 14 11:45:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 14 Dec 2017 11:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2242) Narrow set of thrown
 exceptions in Streamable and Marshaller method signatures
In-Reply-To: <JIRA.12724951.1513269870000@Atlassian.JIRA>
References: <JIRA.12724951.1513269870000@Atlassian.JIRA>
	<JIRA.12724951.1513269870806@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724951.1513269870000.4893.1513269900299@Atlassian.JIRA>

Paul Ferraro created JGRP-2242:
----------------------------------

             Summary: Narrow set of thrown exceptions in Streamable and Marshaller method signatures
                 Key: JGRP-2242
                 URL: https://issues.jboss.org/browse/JGRP-2242
             Project: JGroups
          Issue Type: Enhancement
    Affects Versions: 4.0
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 5.0


These methods all throw a generic Exception.  Write methods should only need to throw IOException, while read methods should only need to throw IOException and ClassNotFoundException.

Original PR, deferred to 5.0, is here:
https://github.com/belaban/JGroups/pull/372



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 12:19:00 2017
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 14 Dec 2017 12:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6464) JPA 2.2 Support
In-Reply-To: <JIRA.12612939.1459635658000@Atlassian.JIRA>
References: <JIRA.12612939.1459635658000@Atlassian.JIRA>
	<JIRA.12612939.1459635658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12612939.1459635658000.5023.1513271940288@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505623#comment-13505623 ] 

Scott Marlow commented on WFLY-6464:
------------------------------------

Close pr [https://github.com/wildfly/wildfly/pull/10715] contains initial changes, also need ability to switch between JPA 2.1 + 2.2 api jars.

> JPA 2.2 Support
> ---------------
>
>                 Key: WFLY-6464
>                 URL: https://issues.jboss.org/browse/WFLY-6464
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 12.0.0.Alpha1
>
>
> From JPA 2.2 specification appendix section A.1:
> {code}
> A.1 Maintenance Release Draft
> Created document from Java Persistence 2.1 Final Release specification.
> The following annotations have been marked @Repeatable:
>  AssociationOverride
>  AttributeOverride
>  Convert
>  JoinColumn
>  MapKeyJoinColumn
>  NamedEntityGraph
>  NamedNativeQuery 
>  NamedQuery
>  NamedStoredProcedureQuery
>  PersistenceContext
>  PersistenceUnit
>  PrimaryKeyJoinColumn
>  SecondaryTable
>  SqlResultSetMapping
>  SequenceGenerator
>  TableGenerator
> Added SequenceGenerators and TableGenerators annotations.
> Added support for CDI injection into AttributeConverter classes.
> Added support for the mapping of the following java.time types:
>  java.time.LocalDate
>  java.time.LocalTime
>  java.time.LocalDateTime
>  java.time.OffsetTime
>  java.time.OffsetDateTime
> Added default Stream getResultStream() method to Query interface.
> Added default Stream<X> getResultStream() method to TypedQuery interface.
> Replaced reference to JAR file specification in persistence provider bootstrapping section with more general reference to Java SE service provider requirements.
> Updated persistence.xml and orm.xml schemas to 2.2 versions.
> Updated Related Documents.
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 14 12:23:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 14 Dec 2017 12:23: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.5040.1513272180299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-283:
---------------------------
    Attachment: openjdk-patch-native-mechs.patch


> 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: openjdk-patch-native-mechs.patch
>
>
> 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 Dec 14 12:25:00 2017
From: issues at jboss.org (Serg Pol (JIRA))
Date: Thu, 14 Dec 2017 12:25: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.5047.1513272300113@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505627#comment-13505627 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

Are these batch threads (max-threads number) used by some other processes (infinispan?) in wildfly 9? 
Or this max number is just limit of threads of BatchJobs that run in the same time?

> 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  Thu Dec 14 12:38:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 14 Dec 2017 12:38: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.5078.1513273080155@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505630#comment-13505630 ] 

Jan Kalina commented on ELY-283:
--------------------------------

Even after patching openjdk to fix issue above (patch in attachement openjdk-patch-native-mechs.patch), the JVM crash in native acceptContext():
{code}
Current thread (0x00007f8bbc3c8000):  JavaThread "management task-1" [_thread_in_native, id=10598, stack(0x00007f8b9b73b000,0x00007f8b9b83c000)]

Stack: [0x00007f8b9b73b000,0x00007f8b9b83c000],  sp=0x00007f8b9b839a20,  free space=1018k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x932b2]  cfree+0x32

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.security.jgss.wrapper.GSSLibStub.acceptContext(JLorg/ietf/jgss/ChannelBinding;[BLsun/security/jgss/wrapper/NativeGSSContext;)[B+0 java.security.jgss at 9-internal
j  sun.security.jgss.wrapper.NativeGSSContext.acceptSecContext(Ljava/io/InputStream;I)[B+68 java.security.jgss at 9-internal
j  sun.security.jgss.GSSContextImpl.acceptSecContext(Ljava/io/InputStream;Ljava/io/OutputStream;)V+233 java.security.jgss at 9-internal
j  sun.security.jgss.GSSContextImpl.acceptSecContext([BII)[B+24 java.security.jgss at 9-internal
j  org.wildfly.security.sasl.gs2.Gs2SaslServer.evaluateMessage(I[B)[B+586
{code}
Looks like this will need some more JDK fixes... I think this issue should be postponed for now, until this will be resolved in JDK...
[~dlofthouse] Do we have contact to OpenJDK developers, to forwared them this issue? (openjdk jira is not public)

> 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: openjdk-patch-native-mechs.patch
>
>
> 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 Dec 14 13:27:00 2017
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Thu, 14 Dec 2017 13:27: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.5119.1513276020154@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505636#comment-13505636 ] 

Cheng Fang commented on WFLY-9610:
----------------------------------

The max-threads attribute in batch subsystem is the max number of threads in the thread pool used only by batch runtime.

> 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  Thu Dec 14 23:51:00 2017
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 14 Dec 2017 23:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9616) Ability to specify thread
 pool used per EJB or deployment
In-Reply-To: <JIRA.12724989.1513313415000@Atlassian.JIRA>
References: <JIRA.12724989.1513313415000@Atlassian.JIRA>
	<JIRA.12724989.1513313415884@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724989.1513313415000.5800.1513313460130@Atlassian.JIRA>

Brad Maxwell created WFLY-9616:
----------------------------------

             Summary: Ability to specify thread pool used per EJB or deployment
                 Key: WFLY-9616
                 URL: https://issues.jboss.org/browse/WFLY-9616
             Project: WildFly
          Issue Type: Feature Request
          Components: EJB
    Affects Versions: 11.0.0.Final
            Reporter: Brad Maxwell


Request the ability to specify a particular thread pool to be used for an EJB or deployment to limit potential deadlocks such as a large number of Async EJB calls invoking other EJBs and not having enough resources to process the request.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 00:01:00 2017
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Fri, 15 Dec 2017 00:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9616) Ability to specify thread
 pool used per EJB or deployment
In-Reply-To: <JIRA.12724989.1513313416000@Atlassian.JIRA>
References: <JIRA.12724989.1513313416000@Atlassian.JIRA>
	<JIRA.12724989.1513313416000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724989.1513313416000.5808.1513314060283@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFLY-9616:
-------------------------------
    Description: Request the ability to specify a particular thread pool to be used for an EJB or deployment to limit potential deadlocks such as a large number of Async EJB calls invoking other EJBs and not having enough resources to process the request.  And a configurable fairness method to prevent one requestor from potentially taking priority.  (was: Request the ability to specify a particular thread pool to be used for an EJB or deployment to limit potential deadlocks such as a large number of Async EJB calls invoking other EJBs and not having enough resources to process the request.)


> Ability to specify thread pool used per EJB or deployment
> ---------------------------------------------------------
>
>                 Key: WFLY-9616
>                 URL: https://issues.jboss.org/browse/WFLY-9616
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>    Affects Versions: 11.0.0.Final
>            Reporter: Brad Maxwell
>
> Request the ability to specify a particular thread pool to be used for an EJB or deployment to limit potential deadlocks such as a large number of Async EJB calls invoking other EJBs and not having enough resources to process the request.  And a configurable fairness method to prevent one requestor from potentially taking priority.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 05:10:00 2017
From: issues at jboss.org (Martin Mazanek (JIRA))
Date: Fri, 15 Dec 2017 05:10:00 -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.6376.1513332600111@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Mazanek reassigned ELY-1405:
-----------------------------------

    Assignee: Martin Mazanek


> 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.Beta11
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 06:34:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 15 Dec 2017 06:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2180) [Guided Rule Editor] NPE
 closing a Guided Rule with an incomplete ActionCallMethod
In-Reply-To: <JIRA.12725255.1513337628000@Atlassian.JIRA>
References: <JIRA.12725255.1513337628000@Atlassian.JIRA>
	<JIRA.12725255.1513337628239@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725255.1513337628000.6583.1513337640074@Atlassian.JIRA>

Michael Anstis created DROOLS-2180:
--------------------------------------

             Summary: [Guided Rule Editor] NPE closing a Guided Rule with an incomplete ActionCallMethod
                 Key: DROOLS-2180
                 URL: https://issues.jboss.org/browse/DROOLS-2180
             Project: Drools
          Issue Type: Bug
          Components: Guided Rule Editor
    Affects Versions: 7.5.0.Final
            Reporter: Michael Anstis
            Assignee: Michael Anstis
            Priority: Minor


The implementation of {{ActionCallMethod.hashCode()}} fails if the "method name" is {{null}}. This scenario can arise if you create a new Guided Rule, add a "Call method on..." action and leave it incomplete. Trying to close the editor results in a NPE error (as the "is dirty" mechanism uses {{hashCode()}} implementations).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 07:18:00 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Fri, 15 Dec 2017 07:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9606) Upgrade ejb-client to
	4.0.10.Final
In-Reply-To: <JIRA.12724281.1513004908000@Atlassian.JIRA>
References: <JIRA.12724281.1513004908000@Atlassian.JIRA>
	<JIRA.12724281.1513004908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724281.1513004908000.6659.1513340280663@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505852#comment-13505852 ] 

Ivo Studensky commented on WFLY-9606:
-------------------------------------

My expectation that JBEAP-12666 needs another fix while it is open was wrong, I am sorry for that. I will close the upgrade issues and move the component jira to ON_QA then.

> Upgrade ejb-client to 4.0.10.Final
> ----------------------------------
>
>                 Key: WFLY-9606
>                 URL: https://issues.jboss.org/browse/WFLY-9606
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: EJB
>            Reporter: Ivo Studensky
>            Assignee: David Lloyd
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 07:21:00 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Fri, 15 Dec 2017 07:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9606) Upgrade ejb-client to
	4.0.10.Final
In-Reply-To: <JIRA.12724281.1513004908000@Atlassian.JIRA>
References: <JIRA.12724281.1513004908000@Atlassian.JIRA>
	<JIRA.12724281.1513004908000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724281.1513004908000.6684.1513340460564@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky closed WFLY-9606.
-------------------------------
    Resolution: Rejected


> Upgrade ejb-client to 4.0.10.Final
> ----------------------------------
>
>                 Key: WFLY-9606
>                 URL: https://issues.jboss.org/browse/WFLY-9606
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: EJB
>            Reporter: Ivo Studensky
>            Assignee: David Lloyd
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 07:34:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 15 Dec 2017 07:34: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.1513341216000@Atlassian.JIRA>
References: <JIRA.12725260.1513341216000@Atlassian.JIRA>
	<JIRA.12725260.1513341216943@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725260.1513341216000.6811.1513341240250@Atlassian.JIRA>

Michael Anstis created DROOLS-2181:
--------------------------------------

             Summary: 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  Fri Dec 15 07:42:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 15 Dec 2017 07:42: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.6882.1513341720169@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505866#comment-13505866 ] 

Michael Anstis commented on DROOLS-2181:
----------------------------------------

Checked {{master}} branch running in IDEA and it works OK.. investigating..

> 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  Fri Dec 15 07:47:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 15 Dec 2017 07:47: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.6899.1513342020412@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505870#comment-13505870 ] 

Michael Anstis commented on DROOLS-2181:
----------------------------------------

6.5.1.Final works OK, but 7.4.x onwards seem flawed.... suggests a change in Lienzo may be causing the problem.. investigating..

> 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  Fri Dec 15 08:07:00 2017
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 15 Dec 2017 08:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3461)
 jboss.as:management-root=server MBean might be filtered on
 queryName/queryMBean methods
In-Reply-To: <JIRA.12725262.1513343205000@Atlassian.JIRA>
References: <JIRA.12725262.1513343205000@Atlassian.JIRA>
	<JIRA.12725262.1513343205787@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725262.1513343205000.6974.1513343220090@Atlassian.JIRA>

Lucas Ponce created WFCORE-3461:
-----------------------------------

             Summary: jboss.as:management-root=server MBean might be filtered on queryName/queryMBean methods
                 Key: WFCORE-3461
                 URL: https://issues.jboss.org/browse/WFCORE-3461
             Project: WildFly Core
          Issue Type: Bug
    Affects Versions: 3.0.8.Final
            Reporter: Lucas Ponce


A queryName/queryMBean using jboss.as:management-root=server as ObjectName might be filtered

https://github.com/wildfly/wildfly-core/blob/3.0.8.Final/jmx/src/main/java/org/jboss/as/jmx/model/ModelControllerMBeanHelper.java#L145

So, this cause that this MBean is not found when it is visible using a full scan.

This has a negative impact on monitoring systems than relay on queryName/queryMBean methods to find specific MBean to monitor.

jboss.as:management-root=server is an important MBean in this context to provider general status of the server.

This issue can be reproduced using the examples:
https://github.com/jmazzitelli/test/tree/master/javaagent




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 09:33:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 09:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3461)
 jboss.as:management-root=server MBean might be filtered on
 queryName/queryMBean methods
In-Reply-To: <JIRA.12725262.1513343206000@Atlassian.JIRA>
References: <JIRA.12725262.1513343206000@Atlassian.JIRA>
	<JIRA.12725262.1513343206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725262.1513343206000.7358.1513348380163@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3461:
-------------------------------------
    Component/s: JMX


> jboss.as:management-root=server MBean might be filtered on queryName/queryMBean methods
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3461
>                 URL: https://issues.jboss.org/browse/WFCORE-3461
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 3.0.8.Final
>            Reporter: Lucas Ponce
>
> A queryName/queryMBean using jboss.as:management-root=server as ObjectName might be filtered
> https://github.com/wildfly/wildfly-core/blob/3.0.8.Final/jmx/src/main/java/org/jboss/as/jmx/model/ModelControllerMBeanHelper.java#L145
> So, this cause that this MBean is not found when it is visible using a full scan.
> This has a negative impact on monitoring systems than relay on queryName/queryMBean methods to find specific MBean to monitor.
> jboss.as:management-root=server is an important MBean in this context to provider general status of the server.
> This issue can be reproduced using the examples:
> https://github.com/jmazzitelli/test/tree/master/javaagent



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 09:34:00 2017
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 15 Dec 2017 09:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3461)
 jboss.as:management-root=server MBean might be filtered on
 queryName/queryMBean methods
In-Reply-To: <JIRA.12725262.1513343206000@Atlassian.JIRA>
References: <JIRA.12725262.1513343206000@Atlassian.JIRA>
	<JIRA.12725262.1513343206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725262.1513343206000.7367.1513348440440@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lucas Ponce updated WFCORE-3461:
--------------------------------
    Description: 
A queryName/queryMBean using jboss.as:management-root=server as ObjectName might be filtered

https://github.com/wildfly/wildfly-core/blob/3.0.8.Final/jmx/src/main/java/org/jboss/as/jmx/model/ModelControllerMBeanHelper.java#L145

So, this cause that this MBean is not found when it is visible using a full scan.

This has a negative impact on monitoring systems than relay on queryName/queryMBean methods to find specific MBean to monitor.

jboss.as:management-root=server is an important MBean in this context to provide general status of the server.

This issue can be reproduced using the examples:
https://github.com/jmazzitelli/test/tree/master/javaagent


  was:
A queryName/queryMBean using jboss.as:management-root=server as ObjectName might be filtered

https://github.com/wildfly/wildfly-core/blob/3.0.8.Final/jmx/src/main/java/org/jboss/as/jmx/model/ModelControllerMBeanHelper.java#L145

So, this cause that this MBean is not found when it is visible using a full scan.

This has a negative impact on monitoring systems than relay on queryName/queryMBean methods to find specific MBean to monitor.

jboss.as:management-root=server is an important MBean in this context to provider general status of the server.

This issue can be reproduced using the examples:
https://github.com/jmazzitelli/test/tree/master/javaagent




> jboss.as:management-root=server MBean might be filtered on queryName/queryMBean methods
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3461
>                 URL: https://issues.jboss.org/browse/WFCORE-3461
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 3.0.8.Final
>            Reporter: Lucas Ponce
>
> A queryName/queryMBean using jboss.as:management-root=server as ObjectName might be filtered
> https://github.com/wildfly/wildfly-core/blob/3.0.8.Final/jmx/src/main/java/org/jboss/as/jmx/model/ModelControllerMBeanHelper.java#L145
> So, this cause that this MBean is not found when it is visible using a full scan.
> This has a negative impact on monitoring systems than relay on queryName/queryMBean methods to find specific MBean to monitor.
> jboss.as:management-root=server is an important MBean in this context to provide general status of the server.
> This issue can be reproduced using the examples:
> https://github.com/jmazzitelli/test/tree/master/javaagent



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 09:40:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 15 Dec 2017 09:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3461)
 jboss.as:management-root=server MBean might be filtered on
 queryName/queryMBean methods
In-Reply-To: <JIRA.12725262.1513343206000@Atlassian.JIRA>
References: <JIRA.12725262.1513343206000@Atlassian.JIRA>
	<JIRA.12725262.1513343206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725262.1513343206000.7416.1513348800476@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFCORE-3461:
----------------------------------

    Assignee: Kabir Khan


> jboss.as:management-root=server MBean might be filtered on queryName/queryMBean methods
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3461
>                 URL: https://issues.jboss.org/browse/WFCORE-3461
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 3.0.8.Final
>            Reporter: Lucas Ponce
>            Assignee: Kabir Khan
>
> A queryName/queryMBean using jboss.as:management-root=server as ObjectName might be filtered
> https://github.com/wildfly/wildfly-core/blob/3.0.8.Final/jmx/src/main/java/org/jboss/as/jmx/model/ModelControllerMBeanHelper.java#L145
> So, this cause that this MBean is not found when it is visible using a full scan.
> This has a negative impact on monitoring systems than relay on queryName/queryMBean methods to find specific MBean to monitor.
> jboss.as:management-root=server is an important MBean in this context to provide general status of the server.
> This issue can be reproduced using the examples:
> https://github.com/jmazzitelli/test/tree/master/javaagent



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 09:51:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 15 Dec 2017 09:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-251) More certain credential based
 mechanism selection.
In-Reply-To: <JIRA.12580133.1438602083000@Atlassian.JIRA>
References: <JIRA.12580133.1438602083000@Atlassian.JIRA>
	<JIRA.12580133.1438602083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580133.1438602083000.7504.1513349460606@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506251#comment-13506251 ] 

Jan Kalina commented on ELY-251:
--------------------------------

Are we able to determine if the mechanism is supported before it is used? Currently we are able to determine if we have appropriate credential in realm only after user provides identity name, which requires to mechanism be already used to communicated this...

> More certain credential based mechanism selection.
> --------------------------------------------------
>
>                 Key: ELY-251
>                 URL: https://issues.jboss.org/browse/ELY-251
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: SASL
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> When filtering authentication mechanisms we need to really be able to offer two modes: -
>  1 - Only offer a mech if we are sure it is supported.
> Risks only offering a weaker mechanism in a mixed domain but also eliminates mechanisms that could fail for a valid user that just happens to have a different credential type.
>  2- More general support.
> i.e. offer the mechs that may be supported.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 10:06:00 2017
From: issues at jboss.org (Domenico Briganti (JIRA))
Date: Fri, 15 Dec 2017 10:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9617) Add persistend store to
 infinispan via CLI fail
In-Reply-To: <JIRA.12725276.1513350336000@Atlassian.JIRA>
References: <JIRA.12725276.1513350336000@Atlassian.JIRA>
	<JIRA.12725276.1513350336846@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725276.1513350336000.7651.1513350360507@Atlassian.JIRA>

Domenico Briganti created WFLY-9617:
---------------------------------------

             Summary: Add persistend store to infinispan via CLI fail
                 Key: WFLY-9617
                 URL: https://issues.jboss.org/browse/WFLY-9617
             Project: WildFly
          Issue Type: Bug
          Components: Clustering, Domain Management
    Affects Versions: 11.0.0.Final
            Reporter: Domenico Briganti
            Assignee: Paul Ferraro


Configure a persistent file for a local-cache via CLI fail if not into a batch block.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 10:11:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 15 Dec 2017 10:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9617) Add persistend store to
 infinispan via CLI fail
In-Reply-To: <JIRA.12725276.1513350337000@Atlassian.JIRA>
References: <JIRA.12725276.1513350337000@Atlassian.JIRA>
	<JIRA.12725276.1513350337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725276.1513350337000.7688.1513350660280@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506270#comment-13506270 ] 

Radoslav Husar commented on WFLY-9617:
--------------------------------------

[~dometec] Needs to be run in a batch. Moreover, always use a batch unless there is a reason not to use batch.

> Add persistend store to infinispan via CLI fail
> -----------------------------------------------
>
>                 Key: WFLY-9617
>                 URL: https://issues.jboss.org/browse/WFLY-9617
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>    Affects Versions: 11.0.0.Final
>            Reporter: Domenico Briganti
>            Assignee: Paul Ferraro
>
> Configure a persistent file for a local-cache via CLI fail if not into a batch block.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 10:19:00 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 15 Dec 2017 10:19: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.7735.1513351140335@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-1946:
--------------------------------
    Attachment: Screen Shot 2017-12-15 at 10.16.33 AM.png


> 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
>
>         Attachments: Screen Shot 2017-12-15 at 10.16.33 AM.png
>
>
> Place holder for all DMN Editor related activities



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 10:22:00 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 15 Dec 2017 10:22: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.7757.1513351320266@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-1946:
--------------------------------
    Attachment:     (was: Screen Shot 2017-12-15 at 10.16.33 AM.png)


> 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  Fri Dec 15 10:23:00 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 15 Dec 2017 10: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.7763.1513351380378@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 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
>         Attachments: Screen Shot 2017-12-15 at 10.16.33 AM.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 Dec 15 10:24:00 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 15 Dec 2017 10:24: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.7773.1513351440626@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506278#comment-13506278 ] 

Liz Clayton commented on DROOLS-2154:
-------------------------------------

[~manstis] [~tirelli] [~mstevens1] I posted a mockup that illustrates the key navigation points, to address this story. I plan to create a separate jira for inline interactions and such.
 !Screen Shot 2017-12-15 at 10.16.33 AM.png|thumbnail! 

> 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 2017-12-15 at 10.16.33 AM.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 Dec 15 11:02:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 15 Dec 2017 11:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3462) Expose the ability for
 filters on loggers to be inherited
In-Reply-To: <JIRA.12725284.1513353666000@Atlassian.JIRA>
References: <JIRA.12725284.1513353666000@Atlassian.JIRA>
	<JIRA.12725284.1513353666530@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725284.1513353666000.7983.1513353720484@Atlassian.JIRA>

James Perkins created WFCORE-3462:
-------------------------------------

             Summary: Expose the ability for filters on loggers to be inherited
                 Key: WFCORE-3462
                 URL: https://issues.jboss.org/browse/WFCORE-3462
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins


In LOGMGR-45 the ability to allow loggers to inherit filters was added. This should also be supported in the management model for WildFly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 11:06:00 2017
From: issues at jboss.org (Christian Bauer (JIRA))
Date: Fri, 15 Dec 2017 11:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2182) NPE when @Expires is
 missing on event type
In-Reply-To: <JIRA.12725285.1513353923000@Atlassian.JIRA>
References: <JIRA.12725285.1513353923000@Atlassian.JIRA>
	<JIRA.12725285.1513353923542@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725285.1513353923000.8014.1513353960136@Atlassian.JIRA>

Christian Bauer created DROOLS-2182:
---------------------------------------

             Summary: 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: Edson Tirelli


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  Fri Dec 15 11:07:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 15 Dec 2017 11:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-187) The
 ClassLoaderLogContextSelector check for the log context should return null
In-Reply-To: <JIRA.12725286.1513353986000@Atlassian.JIRA>
References: <JIRA.12725286.1513353986000@Atlassian.JIRA>
	<JIRA.12725286.1513353986743@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725286.1513353986000.8017.1513354020241@Atlassian.JIRA>

James Perkins created LOGMGR-187:
------------------------------------

             Summary: The ClassLoaderLogContextSelector check for the log context should return null
                 Key: LOGMGR-187
                 URL: https://issues.jboss.org/browse/LOGMGR-187
             Project: JBoss Log Manager
          Issue Type: Bug
            Reporter: James Perkins


The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 11:10:00 2017
From: issues at jboss.org (Duncan Doyle (JIRA))
Date: Fri, 15 Dec 2017 11:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2183) Can't configure KieSession
 used in RuleUnitExecutor
In-Reply-To: <JIRA.12725287.1513354157000@Atlassian.JIRA>
References: <JIRA.12725287.1513354157000@Atlassian.JIRA>
	<JIRA.12725287.1513354157529@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725287.1513354157000.8032.1513354200146@Atlassian.JIRA>

Duncan Doyle created DROOLS-2183:
------------------------------------

             Summary: Can't configure KieSession used in RuleUnitExecutor
                 Key: DROOLS-2183
                 URL: https://issues.jboss.org/browse/DROOLS-2183
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.5.0.Final
         Environment: macOS 10.12.6, Oracle Hotspot 1.8.0_151
            Reporter: Duncan Doyle
            Assignee: Mario Fusco


To support CEP using RuleUnits, we need to be able to configure a session that uses the PseudoClock (a best practice when using deterministic CEP rule execution). However, in the current implementation, the KieSession configuration in kmodule.xml is discarded. Second, there is not a nice way in the current API to pass session configuration programmatically.

A reproducer of the problem can be found here (sorry for not cleaning it up nicely. It basically tries to set the SessionClock as fact into WorkingMemory, and at that time trying to cast to SessionPseudoClock.): https://github.com/DuncanDoyle/rule-unit-and-session-conf

Just run "mvn clean test" on that project.

As discussed on IRC, we agreed that the proper way of doing this would be to make the RuleUnitExecutor a container resource and allow it to use session configuration defined in kmodule.xml (also from a KIE-Server perspective).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 11:37:00 2017
From: issues at jboss.org (Domenico Briganti (JIRA))
Date: Fri, 15 Dec 2017 11:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9617) Add persistend store to
 infinispan via CLI fail
In-Reply-To: <JIRA.12725276.1513350337000@Atlassian.JIRA>
References: <JIRA.12725276.1513350337000@Atlassian.JIRA>
	<JIRA.12725276.1513350337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725276.1513350337000.8148.1513355820299@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506322#comment-13506322 ] 

Domenico Briganti commented on WFLY-9617:
-----------------------------------------

OK, but I have the same error if I want to add a file store in a second moment. If I previously create the cache and now I run:

batch

/subsystem=infinispan/cache-container=reservation/local-cache=authtoken/store=file:add(path=authtoken.dat,relative-to=jboss.home.dir,passivation=false,preload=true,purge=true)

run-batch

I get the same error.
 

> Add persistend store to infinispan via CLI fail
> -----------------------------------------------
>
>                 Key: WFLY-9617
>                 URL: https://issues.jboss.org/browse/WFLY-9617
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>    Affects Versions: 11.0.0.Final
>            Reporter: Domenico Briganti
>            Assignee: Paul Ferraro
>
> Configure a persistent file for a local-cache via CLI fail if not into a batch block.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 11:46:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 15 Dec 2017 11:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9617) Add persistend store to
 infinispan via CLI fail
In-Reply-To: <JIRA.12725276.1513350337000@Atlassian.JIRA>
References: <JIRA.12725276.1513350337000@Atlassian.JIRA>
	<JIRA.12725276.1513350337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725276.1513350337000.8196.1513356360329@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506327#comment-13506327 ] 

Radoslav Husar commented on WFLY-9617:
--------------------------------------

The whole add operation for the cache needs to be run in a batch:

{noformat}
batch
/subsystem=infinispan/cache-container=reservation:add
/subsystem=infinispan/cache-container=reservation/local-cache=authtoken:add(statistics-enabled=true)
/subsystem=infinispan/cache-container=reservation/local-cache=authtoken/store=file:add(path=authtoken.dat,relative-to=jboss.home.dir,passivation=false,preload=true,purge=true)
run-batch
{noformat}


> Add persistend store to infinispan via CLI fail
> -----------------------------------------------
>
>                 Key: WFLY-9617
>                 URL: https://issues.jboss.org/browse/WFLY-9617
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>    Affects Versions: 11.0.0.Final
>            Reporter: Domenico Briganti
>            Assignee: Paul Ferraro
>
> Configure a persistent file for a local-cache via CLI fail if not into a batch block.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 11:59:01 2017
From: issues at jboss.org (Domenico Briganti (JIRA))
Date: Fri, 15 Dec 2017 11:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9617) Add persistend store to
 infinispan via CLI fail
In-Reply-To: <JIRA.12725276.1513350337000@Atlassian.JIRA>
References: <JIRA.12725276.1513350337000@Atlassian.JIRA>
	<JIRA.12725276.1513350337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725276.1513350337000.8240.1513357141341@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506332#comment-13506332 ] 

Domenico Briganti commented on WFLY-9617:
-----------------------------------------

Ok. So it is not possible to configure a persistent store in an existent cache, correct? (only hacking the standalone.xml file :) )

> Add persistend store to infinispan via CLI fail
> -----------------------------------------------
>
>                 Key: WFLY-9617
>                 URL: https://issues.jboss.org/browse/WFLY-9617
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>    Affects Versions: 11.0.0.Final
>            Reporter: Domenico Briganti
>            Assignee: Paul Ferraro
>
> Configure a persistent file for a local-cache via CLI fail if not into a batch block.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 12:00:00 2017
From: issues at jboss.org (Ashish Agarwal (JIRA))
Date: Fri, 15 Dec 2017 12:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2064) JDBC_PING: make subclass of
	FILE_PING
In-Reply-To: <JIRA.12626531.1463560438000@Atlassian.JIRA>
References: <JIRA.12626531.1463560438000@Atlassian.JIRA>
	<JIRA.12626531.1463560438000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626531.1463560438000.8244.1513357200400@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506333#comment-13506333 ] 

Ashish Agarwal commented on JGRP-2064:
--------------------------------------

I tried using remove_old_coords_on_view_change and remove_all_files_on_view_change  in my xml file but its not working

Please suggest.

My xml looks like this :
<JDBC_PING connection_url="DB url"
               connection_username="user_name" connection_password="password"
               connection_driver="oracle.jdbc.OracleDriver"
               remove_old_coords_on_view_change="true"
               initialize_sql="CREATE TABLE IF NOT EXISTS jgroup_ping (
                       own_addr varchar(200) NOT NULL,
                                    cluster_name varchar(200) NOT NULL,
                                    ping_data varbinary(5000) DEFAULT NULL,
                                    PRIMARY KEY (own_addr, cluster_name)
                       )ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin"

               insert_single_sql="INSERT INTO jgroup_ping (own_addr, cluster_name, ping_data) values (?, ?, ?)"
               delete_single_sql="DELETE FROM jgroup_ping WHERE own_addr=? AND cluster_name=?"
               select_all_pingdata_sql="SELECT ping_data FROM jgroup_ping WHERE cluster_name=?" />

> JDBC_PING: make subclass of FILE_PING
> -------------------------------------
>
>                 Key: JGRP-2064
>                 URL: https://issues.jboss.org/browse/JGRP-2064
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0
>
>
> This way, zombie removal would be possible, e.g. attributes {{remove_old_coords_on_view_change}} and {{remove_all_files_on_view_change}} would be usable.
> Currently, JDBC_PING extends Discovery only, not FILE_PING



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 12:00:01 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 15 Dec 2017 12:00:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357200000@Atlassian.JIRA>
References: <JIRA.12725294.1513357200000@Atlassian.JIRA>
	<JIRA.12725294.1513357200649@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357200000.8253.1513357201771@Atlassian.JIRA>

Liz Clayton created DROOLS-2184:
-----------------------------------

             Summary: 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


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 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 Dec 15 12:03:00 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 15 Dec 2017 12:03: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.8259.1513357380118@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2184:
--------------------------------
    Description: 
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. 

  was:
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 perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



> 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  Fri Dec 15 12:30:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 15 Dec 2017 12:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9617) Add persistend store to
 infinispan via CLI fail
In-Reply-To: <JIRA.12725276.1513350337000@Atlassian.JIRA>
References: <JIRA.12725276.1513350337000@Atlassian.JIRA>
	<JIRA.12725276.1513350337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725276.1513350337000.8350.1513359000484@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506344#comment-13506344 ] 

Radoslav Husar commented on WFLY-9617:
--------------------------------------

To configure on an existing cache, there are multiple options. On a running server, pass a flag to allow services to restart, e.g.:

{noformat}
/subsystem=infinispan/cache-container=web/distributed-cache=dist/store=none:add{allow-resource-service-restart=true
{noformat}

But typiacally, one would start the server in {{--admin-only}} mode and  do the required configuration.

> Add persistend store to infinispan via CLI fail
> -----------------------------------------------
>
>                 Key: WFLY-9617
>                 URL: https://issues.jboss.org/browse/WFLY-9617
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>    Affects Versions: 11.0.0.Final
>            Reporter: Domenico Briganti
>            Assignee: Paul Ferraro
>
> Configure a persistent file for a local-cache via CLI fail if not into a batch block.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 12:31:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 15 Dec 2017 12:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9617) Add persistend store to
 infinispan via CLI fail
In-Reply-To: <JIRA.12725276.1513350337000@Atlassian.JIRA>
References: <JIRA.12725276.1513350337000@Atlassian.JIRA>
	<JIRA.12725276.1513350337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725276.1513350337000.8355.1513359060257@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506344#comment-13506344 ] 

Radoslav Husar edited comment on WFLY-9617 at 12/15/17 12:30 PM:
-----------------------------------------------------------------

To configure on an existing cache, there are multiple options. On a running server, pass a flag to allow services to restart, e.g.:

{noformat}
/subsystem=infinispan/cache-container=web/distributed-cache=dist/store=none:add{allow-resource-service-restart=true
{noformat}

But typically, one would start the server in {{--admin-only}} mode and  do the required configuration.


was (Author: rhusar):
To configure on an existing cache, there are multiple options. On a running server, pass a flag to allow services to restart, e.g.:

{noformat}
/subsystem=infinispan/cache-container=web/distributed-cache=dist/store=none:add{allow-resource-service-restart=true
{noformat}

But typiacally, one would start the server in {{--admin-only}} mode and  do the required configuration.

> Add persistend store to infinispan via CLI fail
> -----------------------------------------------
>
>                 Key: WFLY-9617
>                 URL: https://issues.jboss.org/browse/WFLY-9617
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>    Affects Versions: 11.0.0.Final
>            Reporter: Domenico Briganti
>            Assignee: Paul Ferraro
>
> Configure a persistent file for a local-cache via CLI fail if not into a batch block.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 14:22:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 15 Dec 2017 14:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9617) Add persistend store to
 infinispan via CLI fail
In-Reply-To: <JIRA.12725276.1513350337000@Atlassian.JIRA>
References: <JIRA.12725276.1513350337000@Atlassian.JIRA>
	<JIRA.12725276.1513350337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725276.1513350337000.8565.1513365720409@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-9617.
------------------------------
    Resolution: Rejected


When executing a .../store=*:add operation to an existing cache, you need to use the {allow-resource-service-restart=true} flag.  This ensures that the conflicting resource is removed before the new store is added, and that the associated services are restarted.

> Add persistend store to infinispan via CLI fail
> -----------------------------------------------
>
>                 Key: WFLY-9617
>                 URL: https://issues.jboss.org/browse/WFLY-9617
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>    Affects Versions: 11.0.0.Final
>            Reporter: Domenico Briganti
>            Assignee: Paul Ferraro
>
> Configure a persistent file for a local-cache via CLI fail if not into a batch block.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 16:00:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3457) Minimise 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.8745.1513371603262@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.Alpha6
                       (was: 4.0.0.Alpha5)


> Minimise 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 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.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 16:00:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3455) Reduce unnecessary lambda
	usage
In-Reply-To: <JIRA.12724511.1513103359000@Atlassian.JIRA>
References: <JIRA.12724511.1513103359000@Atlassian.JIRA>
	<JIRA.12724511.1513103359000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724511.1513103359000.8748.1513371603344@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3455:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha6
                       (was: 4.0.0.Alpha5)


> Reduce unnecessary lambda usage
> -------------------------------
>
>                 Key: WFCORE-3455
>                 URL: https://issues.jboss.org/browse/WFCORE-3455
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha6
>
>
> Lambdas chew up a lot of resources and we use a lot of them.  Eliminate whenever possible.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 16:00:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3444) Update wildfly-build-tools
 to 1.2.3.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.8751.1513371603413@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3444:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha6
                       (was: 4.0.0.Alpha5)


> Update wildfly-build-tools to 1.2.3.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  Fri Dec 15 16:00:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00: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.8754.1513371603476@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 16:00:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00: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.8759.1513371603587@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00: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.8766.1513371603782@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 16:00:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:04 -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.8774.1513371604017@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:04 -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.8781.1513371604200@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00: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.8783.1513371604306@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00: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.8790.1513371604619@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00: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.8795.1513371604959@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:05 -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.8797.1513371605072@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:05 -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.8806.1513371605486@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:05 -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.8809.1513371605682@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:05 -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.8812.1513371605822@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2857:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha6
                       (was: 4.0.0.Alpha5)


> 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  Fri Dec 15 16:00:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:06 -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.8820.1513371606225@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:06 -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.8823.1513371606380@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 16:00:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:06 -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.8831.1513371606990@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:07 -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.8846.1513371607261@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:07 -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.8837.1513371607102@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:07 -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.8849.1513371607309@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>         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 Dec 15 16:00:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:07 -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.8844.1513371607229@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:07 -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.8860.1513371607571@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:07 -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.8856.1513371607505@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:07 -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.8864.1513371607646@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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 Dec 15 16:00:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:07 -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.8874.1513371607951@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.Alpha6
                       (was: 4.0.0.Alpha5)


> 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.Alpha6
>
>
> 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  Fri Dec 15 16:00:08 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:00:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.8879.1513371608076@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-887:
------------------------------------
    Fix Version/s: 4.0.0.Alpha6
                       (was: 4.0.0.Alpha5)


> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
>                 Key: WFCORE-887
>                 URL: https://issues.jboss.org/browse/WFCORE-887
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Alpha6
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We use INFO messages for other management API deprecation messages, but these I believe deserve a WARN. The issue here isn't just that we may change something in the future (seen as not justifying a WARN) but also that the capability/requirement bookkeeping for the attribute cannot be properly done if an expression is used, meaning the model integrity behavior meant to be in place cannot be used.
> We should look for other cases like this too, although those changes should be separate JIRAs. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 16:10:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 15 Dec 2017 16:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-187) The
 ClassLoaderLogContextSelector check for the log context should return null
In-Reply-To: <JIRA.12725286.1513353987000@Atlassian.JIRA>
References: <JIRA.12725286.1513353987000@Atlassian.JIRA>
	<JIRA.12725286.1513353987000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725286.1513353987000.8889.1513372200126@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned LOGMGR-187:
------------------------------------

    Assignee: James Perkins


> The ClassLoaderLogContextSelector check for the log context should return null
> ------------------------------------------------------------------------------
>
>                 Key: LOGMGR-187
>                 URL: https://issues.jboss.org/browse/LOGMGR-187
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 16:12:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 16:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7298) Testsuite IO ops housekeeping
In-Reply-To: <JIRA.12654467.1476283813000@Atlassian.JIRA>
References: <JIRA.12654467.1476283813000@Atlassian.JIRA>
	<JIRA.12654467.1476283813000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654467.1476283813000.8892.1513372320112@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506391#comment-13506391 ] 

Brian Stansberry commented on WFLY-7298:
----------------------------------------

If there's any further work on this please open a new issue.

> Testsuite IO ops housekeeping
> -----------------------------
>
>                 Key: WFLY-7298
>                 URL: https://issues.jboss.org/browse/WFLY-7298
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 12.0.0.Alpha1
>
>
> Do some needed housekeeping of testsuite



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 16:47:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 15 Dec 2017 16:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-187) The
 ClassLoaderLogContextSelector check for the log context should return null
In-Reply-To: <JIRA.12725286.1513353987000@Atlassian.JIRA>
References: <JIRA.12725286.1513353987000@Atlassian.JIRA>
	<JIRA.12725286.1513353987000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725286.1513353987000.8921.1513374420095@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-187:
---------------------------------
    Description: 
The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}.

{code:title=Previous Version}
 private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() {
    public LogContext run() {
        for (Class<?> caller : GATEWAY.getClassContext()) {
            final ClassLoader classLoader = caller.getClassLoader();
            final LogContext result = check(classLoader);
            if (result != null) {
                return result;
            }
        }
        return defaultSelector.getLogContext();
    }

    private LogContext check(final ClassLoader classLoader) {
        if (classLoader != null && !logApiClassLoaders.contains(classLoader)) {
            final LogContext context = contextMap.get(classLoader);
            if (context != null) {
                return context;
            }
            if (checkParentClassLoaders) {
                return check(classLoader.getParent());
            }
        }
        return null;
    }
};
{code}

{code:title=Current Version}
private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() {
    public LogContext run() {
        final Class<?> callingClass = JDKSpecific.findCallingClass(logApiClassLoaders);
        return callingClass == null ? defaultSelector.getLogContext() : check(callingClass.getClassLoader());
    }

    private LogContext check(final ClassLoader classLoader) {
        final LogContext context = contextMap.get(classLoader);
        if (context != null) {
            return context;
        }
        final ClassLoader parent = classLoader.getParent();
        if (parent != null && checkParentClassLoaders && ! logApiClassLoaders.contains(parent)) {
            return check(parent);
        }
        return defaultSelector.getLogContext();
    }
};
{code}

The new version only checks the first caller found, then returns the default. The older version checks the callers until it finds a non-null value finally returning the default if no callers were found with associated contexts.


  was:The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}.



> The ClassLoaderLogContextSelector check for the log context should return null
> ------------------------------------------------------------------------------
>
>                 Key: LOGMGR-187
>                 URL: https://issues.jboss.org/browse/LOGMGR-187
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}.
> {code:title=Previous Version}
>  private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() {
>     public LogContext run() {
>         for (Class<?> caller : GATEWAY.getClassContext()) {
>             final ClassLoader classLoader = caller.getClassLoader();
>             final LogContext result = check(classLoader);
>             if (result != null) {
>                 return result;
>             }
>         }
>         return defaultSelector.getLogContext();
>     }
>     private LogContext check(final ClassLoader classLoader) {
>         if (classLoader != null && !logApiClassLoaders.contains(classLoader)) {
>             final LogContext context = contextMap.get(classLoader);
>             if (context != null) {
>                 return context;
>             }
>             if (checkParentClassLoaders) {
>                 return check(classLoader.getParent());
>             }
>         }
>         return null;
>     }
> };
> {code}
> {code:title=Current Version}
> private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() {
>     public LogContext run() {
>         final Class<?> callingClass = JDKSpecific.findCallingClass(logApiClassLoaders);
>         return callingClass == null ? defaultSelector.getLogContext() : check(callingClass.getClassLoader());
>     }
>     private LogContext check(final ClassLoader classLoader) {
>         final LogContext context = contextMap.get(classLoader);
>         if (context != null) {
>             return context;
>         }
>         final ClassLoader parent = classLoader.getParent();
>         if (parent != null && checkParentClassLoaders && ! logApiClassLoaders.contains(parent)) {
>             return check(parent);
>         }
>         return defaultSelector.getLogContext();
>     }
> };
> {code}
> The new version only checks the first caller found, then returns the default. The older version checks the callers until it finds a non-null value finally returning the default if no callers were found with associated contexts.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 15 18:07:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Dec 2017 18:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3463) EmbeddedProcessFactory
 should not require classes meant to be loaded from the modular classloader
In-Reply-To: <JIRA.12725320.1513379200000@Atlassian.JIRA>
References: <JIRA.12725320.1513379200000@Atlassian.JIRA>
	<JIRA.12725320.1513379200869@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725320.1513379200000.9015.1513379220088@Atlassian.JIRA>

Brian Stansberry created WFCORE-3463:
----------------------------------------

             Summary: EmbeddedProcessFactory should not require classes meant to be loaded from the modular classloader
                 Key: WFCORE-3463
                 URL: https://issues.jboss.org/browse/WFCORE-3463
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


EmbeddedProcessFactory is loading EmbeddedHostControllerFactory and EmbeddedStandaloneServerFactory using its own classloader solely in order to get their names in order to pass those into the modular classloader. This unnecessarily ties the embedding app classloading environment to the embedded server side.

This is minor as it doesn't really cause any harm. It's just a cleanup to help make it easier to divide the two sides.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Dec 16 03:25:00 2017
From: issues at jboss.org (Domenico Briganti (JIRA))
Date: Sat, 16 Dec 2017 03:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9617) Add persistend store to
 infinispan via CLI fail
In-Reply-To: <JIRA.12725276.1513350337000@Atlassian.JIRA>
References: <JIRA.12725276.1513350337000@Atlassian.JIRA>
	<JIRA.12725276.1513350337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725276.1513350337000.9057.1513412700166@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506416#comment-13506416 ] 

Domenico Briganti commented on WFLY-9617:
-----------------------------------------

Ok, understand. Thanks.

> Add persistend store to infinispan via CLI fail
> -----------------------------------------------
>
>                 Key: WFLY-9617
>                 URL: https://issues.jboss.org/browse/WFLY-9617
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>    Affects Versions: 11.0.0.Final
>            Reporter: Domenico Briganti
>            Assignee: Paul Ferraro
>
> Configure a persistent file for a local-cache via CLI fail if not into a batch block.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Dec 16 04:37:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 16 Dec 2017 04:37: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.9080.1513417020196@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506420#comment-13506420 ] 

Darran Lofthouse commented on ELY-283:
--------------------------------------

[~dmlloyd] Do you have an recommendations for contact?

Overall we have run into a few issues we believe are JVM issues - maybe if we connect with them we can work on a few different issues.

> 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: openjdk-patch-native-mechs.patch
>
>
> 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  Sun Dec 17 14:27:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Sun, 17 Dec 2017 14:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9618) Record and report stack trace
 of setRollbackOnly() calls
In-Reply-To: <JIRA.12725415.1513538772000@Atlassian.JIRA>
References: <JIRA.12725415.1513538772000@Atlassian.JIRA>
	<JIRA.12725415.1513538772412@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725415.1513538772000.102.1513538820115@Atlassian.JIRA>

David Lloyd created WFLY-9618:
---------------------------------

             Summary: Record and report stack trace of setRollbackOnly() calls
                 Key: WFLY-9618
                 URL: https://issues.jboss.org/browse/WFLY-9618
             Project: WildFly
          Issue Type: Enhancement
          Components: EJB, Transactions
            Reporter: David Lloyd


We should track the stack trace of the first, or of each, caller of setRollbackOnly(), and if the transaction ultimately throws RollbackException or similar, we can add the stack trace as a cause.  If multiple calls are done, then the latest should be the cause and the earlier should show up as suppressed exceptions.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 18 01:33:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 18 Dec 2017 01:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1469) Create profile for running
 only tests which are stable on all platforms
In-Reply-To: <JIRA.12725436.1513578742000@Atlassian.JIRA>
References: <JIRA.12725436.1513578742000@Atlassian.JIRA>
	<JIRA.12725436.1513578742851@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725436.1513578742000.509.1513578780130@Atlassian.JIRA>

Ondrej Lukas created ELY-1469:
---------------------------------

             Summary: Create profile for running only tests which are stable on all platforms
                 Key: ELY-1469
                 URL: https://issues.jboss.org/browse/ELY-1469
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: Testsuite
    Affects Versions: 1.2.0.Beta10
            Reporter: Ondrej Lukas
            Assignee: Ondrej Lukas


Create profile {{stable-tests}} which will exclude all tests which are not stable on any supported platform. This profile must be turned off as default and will be enabled through passing {{-Dstable-tests}} property to maven command.

This profile will serve for running testsuite on all supported platform and fail of any test will be unexpected (i.e. it can be simply checked whether everything is ok). This profile will be useful for CI smoke testing on every supported platforms (current tests during pull requests are run only on RHEL and Windows).

Tests and TestSuite which should be currently excluded (and possibly fixed in the future):
* GssapiTestSuite
* SelfSignedX509CertificateAndSigningKeyTest 
* KeyStoreCredentialStoreTest



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 18 03:11:00 2017
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Mon, 18 Dec 2017 03:11: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.712.1513584660302@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


> 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
>         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  Mon Dec 18 06:55:00 2017
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Mon, 18 Dec 2017 06:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2186)
 ArrayIndexOutOfBoudsException thrown when evaluating query with || operator
In-Reply-To: <JIRA.12725470.1513598060000@Atlassian.JIRA>
References: <JIRA.12725470.1513598060000@Atlassian.JIRA>
	<JIRA.12725470.1513598060018@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725470.1513598060000.1581.1513598100515@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2186:
-------------------------------------

             Summary: ArrayIndexOutOfBoudsException thrown when evaluating query with || operator 
                 Key: DROOLS-2186
                 URL: https://issues.jboss.org/browse/DROOLS-2186
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Mario Fusco
            Priority: Minor


When running test QueryBadResultTest.testQueryCalledWithoutParamsButItHasParams without checking RuntimeException, the test fails with this stacktrace [1].

[1] https://gist.github.com/baldimir/2cf8ff7079bed2284b38096fa7ab9a23



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Dec 18 06:55:00 2017
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Mon, 18 Dec 2017 06:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2186)
 ArrayIndexOutOfBoundsException thrown when evaluating query with ||
 operator
In-Reply-To: <JIRA.12725470.1513598060000@Atlassian.JIRA>
References: <JIRA.12725470.1513598060000@Atlassian.JIRA>
	<JIRA.12725470.1513598060000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725470.1513598060000.1584.1513598100675@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tibor Zim?nyi updated DROOLS-2186:
----------------------------------
    Summary: ArrayIndexOutOfBoundsException thrown when evaluating query with || operator   (was: ArrayIndexOutOfBoudsException thrown when evaluating query with || operator )


> ArrayIndexOutOfBoundsException thrown when evaluating query with || operator 
> -----------------------------------------------------------------------------
>
>                 Key: DROOLS-2186
>                 URL: https://issues.jboss.org/browse/DROOLS-2186
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Mario Fusco
>            Priority: Minor
>
> When running test QueryBadResultTest.testQueryCalledWithoutParamsButItHasParams without checking RuntimeException, the test fails with this stacktrace [1].
> [1] https://gist.github.com/baldimir/2cf8ff7079bed2284b38096fa7ab9a23



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Dec 18 07:10:00 2017
From: issues at jboss.org (David Le Borgne (JIRA))
Date: Mon, 18 Dec 2017 07:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9619) Add an option to configure
 the service display name during service install
In-Reply-To: <JIRA.12725476.1513598972000@Atlassian.JIRA>
References: <JIRA.12725476.1513598972000@Atlassian.JIRA>
	<JIRA.12725476.1513598972084@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725476.1513598972000.1697.1513599000183@Atlassian.JIRA>

David Le Borgne created WFLY-9619:
-------------------------------------

             Summary: Add an option to configure the service display name during service install
                 Key: WFLY-9619
                 URL: https://issues.jboss.org/browse/WFLY-9619
             Project: WildFly
          Issue Type: Feature Request
          Components: Scripts
            Reporter: David Le Borgne
            Assignee: Tomaz Cerar
            Priority: Minor


The docs/contrib/scripts/service.bat lacks an option to configure the service display name during service installation. The service display name will take the value of the service name.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 18 07:31:00 2017
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Mon, 18 Dec 2017 07:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2187) Test
 LiveQueriesBadResultTest.testOfBadParameters fails on NPE
In-Reply-To: <JIRA.12725480.1513600206000@Atlassian.JIRA>
References: <JIRA.12725480.1513600206000@Atlassian.JIRA>
	<JIRA.12725480.1513600206636@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725480.1513600206000.1771.1513600260358@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2187:
-------------------------------------

             Summary: Test LiveQueriesBadResultTest.testOfBadParameters fails on NPE
                 Key: DROOLS-2187
                 URL: https://issues.jboss.org/browse/DROOLS-2187
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Tibor Zim?nyi
            Assignee: Mario Fusco
            Priority: Minor


When test LiveQueriesBadResultTest.testOfBadParameters is run with ignoring the expected exception, it fails on NPE with this stacktrace [1]. This might be related to problem from DROOLS-2186 [2].

[1] https://gist.github.com/baldimir/b6ad1182ce1ad816b2ad47afa8210e79
[2] https://issues.jboss.org/browse/DROOLS-2186



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Dec 18 08:50:00 2017
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Mon, 18 Dec 2017 08:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2188) Remove expected =
 RuntimeException.class attribute from tests
In-Reply-To: <JIRA.12725487.1513604957000@Atlassian.JIRA>
References: <JIRA.12725487.1513604957000@Atlassian.JIRA>
	<JIRA.12725487.1513604957965@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725487.1513604957000.1955.1513605000242@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2188:
-------------------------------------

             Summary: Remove expected = RuntimeException.class attribute from tests
                 Key: DROOLS-2188
                 URL: https://issues.jboss.org/browse/DROOLS-2188
             Project: Drools
          Issue Type: Task
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Tibor Zim?nyi
             Fix For: 7.6.0.Final


Some tests have @Test annotations with attribute expected = RuntimeException.class. This is too general and can hide bugs in related area that end with RuntimeException. E.g. see [1]. 

[1] https://issues.jboss.org/browse/DROOLS-2186



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Dec 18 10:33:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 18 Dec 2017 10:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3464) Fix build for JDK10
In-Reply-To: <JIRA.12725503.1513611130000@Atlassian.JIRA>
References: <JIRA.12725503.1513611130000@Atlassian.JIRA>
	<JIRA.12725503.1513611130721@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725503.1513611130000.2470.1513611180429@Atlassian.JIRA>

Tomaz Cerar created WFCORE-3464:
-----------------------------------

             Summary: Fix build for JDK10
                 Key: WFCORE-3464
                 URL: https://issues.jboss.org/browse/WFCORE-3464
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management, Scripts, Server
         Environment: JDK10
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


Currently we have quite few issues when running on JDK10.

it mostly looks related to version detection code that fails to properly detect 10. 
same goes for many dependent components.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 18 10:44:05 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44:05 -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.2554.1513611845814@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  (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)


> 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 Dec 18 10:44:08 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44:08 -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.2623.1513611848266@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  (was: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50)


> [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 Dec 18 10:44:08 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44:08 -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.2630.1513611848447@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  (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)


> 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 Dec 18 10:44:08 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44:08 -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.2638.1513611848733@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  (was: 2017 Week 36-37, 2017 Week 49-50)


> [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  Mon Dec 18 10:44:09 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44: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.2647.1513611849098@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  (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)


> [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 Dec 18 10:44:09 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44: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.2673.1513611849962@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  (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)


> 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 Dec 18 10:44:11 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44:11 -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.2704.1513611851179@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2154:
-----------------------------------
    Sprint: 2017 Week 49-50, 2017 Week 51-52  (was: 2017 Week 49-50)


> 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 2017-12-15 at 10.16.33 AM.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  Mon Dec 18 10:44:11 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44: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.2711.1513611851392@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  (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)


> [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 Dec 18 10:44:12 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44: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.2737.1513611852126@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  (was: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50)


> 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 Dec 18 10:44:12 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44: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.2746.1513611852354@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  (was: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50)


> 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 Dec 18 10:44:12 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44: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.2749.1513611852452@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  (was: 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50)


> [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 Dec 18 10:44:12 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44: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.2760.1513611852815@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  (was: 2017 Week 49-50)


> 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  Mon Dec 18 10:44:12 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44: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.2764.1513611852904@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  (was: 2017 Week 49-50)


> 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  Mon Dec 18 10:44:13 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2168) Extend concurrency test
	coverage
In-Reply-To: <JIRA.12723924.1512650027000@Atlassian.JIRA>
References: <JIRA.12723924.1512650027000@Atlassian.JIRA>
	<JIRA.12723924.1512650027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723924.1512650027000.2769.1513611853139@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2168:
-----------------------------------
    Sprint: 2017 Week 49-50, 2017 Week 51-52  (was: 2017 Week 49-50)


> Extend concurrency test coverage
> --------------------------------
>
>                 Key: DROOLS-2168
>                 URL: https://issues.jboss.org/browse/DROOLS-2168
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Tibor Zim?nyi
>             Fix For: 7.6.0.Final
>
>
> Coverage for concurrency scenarios must be extended (E.g. coverage using subnetworks, sharing sessions, etc. ).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Dec 18 10:44:13 2017
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 18 Dec 2017 10:44: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.2785.1513611853592@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  (was: 2017 Week 49-50)


> 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  Mon Dec 18 11:10:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 18 Dec 2017 11:10: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.1513613351109@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725507.1513613351000.2946.1513613400457@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-214:
-----------------------------------------

             Summary: [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

Disable Middleware Manager provider in CFME Tests framework.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 18 11:11:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 18 Dec 2017 11:11: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.1513613439051@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725508.1513613439000.2972.1513613460681@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-215:
-----------------------------------------

             Summary: 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  Mon Dec 18 11:12:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 18 Dec 2017 11:12: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.1513613482436@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725510.1513613482000.2976.1513613520278@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-216:
-----------------------------------------

             Summary: 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  Mon Dec 18 11:17:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 18 Dec 2017 11:17:00 -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.3031.1513613820896@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506783#comment-13506783 ] 

Edson Tirelli commented on DROOLS-2161:
---------------------------------------

[~fedor.gavrilov] if this is fixed, can you please "resolve" this ticket?

> 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  Mon Dec 18 11:18:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 18 Dec 2017 11:18: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.3042.1513613880338@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-2182:
-------------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> 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  Mon Dec 18 11:35:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 18 Dec 2017 11:35: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.3182.1513614900084@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506802#comment-13506802 ] 

Mario Fusco commented on DROOLS-2182:
-------------------------------------

I have many test cases using events without any expiration and I've never seen this problem. Do you have a reproducer for this NPE? If so can you please attach it here or at least explain in a bit more detail what I should do to recreate this issue. Just having an event without @Expires annotation doesn't seem to be enough.

> 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  Mon Dec 18 13:06:00 2017
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Mon, 18 Dec 2017 13:06: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.1513620337494@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725521.1513620337000.3487.1513620360128@Atlassian.JIRA>

Toni Rikkola created DROOLS-2189:
------------------------------------

             Summary: 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  Mon Dec 18 15:49:00 2017
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Mon, 18 Dec 2017 15:49: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.3832.1513630140548@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton resolved DROOLS-2154.
---------------------------------
    Resolution: Done


> 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 2017-12-15 at 10.16.33 AM.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  Mon Dec 18 16:24:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 18 Dec 2017 16:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-187) The
 ClassLoaderLogContextSelector check for the log context should return null
In-Reply-To: <JIRA.12725286.1513353987000@Atlassian.JIRA>
References: <JIRA.12725286.1513353987000@Atlassian.JIRA>
	<JIRA.12725286.1513353987000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725286.1513353987000.3853.1513632240095@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-187:
---------------------------------
    Fix Version/s: 2.1.0.Alpha6


> The ClassLoaderLogContextSelector check for the log context should return null
> ------------------------------------------------------------------------------
>
>                 Key: LOGMGR-187
>                 URL: https://issues.jboss.org/browse/LOGMGR-187
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 2.1.0.Alpha6
>
>
> The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}.
> {code:title=Previous Version}
>  private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() {
>     public LogContext run() {
>         for (Class<?> caller : GATEWAY.getClassContext()) {
>             final ClassLoader classLoader = caller.getClassLoader();
>             final LogContext result = check(classLoader);
>             if (result != null) {
>                 return result;
>             }
>         }
>         return defaultSelector.getLogContext();
>     }
>     private LogContext check(final ClassLoader classLoader) {
>         if (classLoader != null && !logApiClassLoaders.contains(classLoader)) {
>             final LogContext context = contextMap.get(classLoader);
>             if (context != null) {
>                 return context;
>             }
>             if (checkParentClassLoaders) {
>                 return check(classLoader.getParent());
>             }
>         }
>         return null;
>     }
> };
> {code}
> {code:title=Current Version}
> private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() {
>     public LogContext run() {
>         final Class<?> callingClass = JDKSpecific.findCallingClass(logApiClassLoaders);
>         return callingClass == null ? defaultSelector.getLogContext() : check(callingClass.getClassLoader());
>     }
>     private LogContext check(final ClassLoader classLoader) {
>         final LogContext context = contextMap.get(classLoader);
>         if (context != null) {
>             return context;
>         }
>         final ClassLoader parent = classLoader.getParent();
>         if (parent != null && checkParentClassLoaders && ! logApiClassLoaders.contains(parent)) {
>             return check(parent);
>         }
>         return defaultSelector.getLogContext();
>     }
> };
> {code}
> The new version only checks the first caller found, then returns the default. The older version checks the callers until it finds a non-null value finally returning the default if no callers were found with associated contexts.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 18 16:25:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 18 Dec 2017 16:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-187) The
 ClassLoaderLogContextSelector check for the log context should return null
In-Reply-To: <JIRA.12725286.1513353987000@Atlassian.JIRA>
References: <JIRA.12725286.1513353987000@Atlassian.JIRA>
	<JIRA.12725286.1513353987000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725286.1513353987000.3855.1513632300124@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-187:
---------------------------------
    Priority: Blocker  (was: Major)


> The ClassLoaderLogContextSelector check for the log context should return null
> ------------------------------------------------------------------------------
>
>                 Key: LOGMGR-187
>                 URL: https://issues.jboss.org/browse/LOGMGR-187
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Blocker
>             Fix For: 2.1.0.Alpha6
>
>
> The {{ClassLoaderLogContextSelector}} check for the registered {{LogContext}} returns {{defaultSelector.getLogContext()}} in the {{check()}} method and should return {{null}}.
> {code:title=Previous Version}
>  private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() {
>     public LogContext run() {
>         for (Class<?> caller : GATEWAY.getClassContext()) {
>             final ClassLoader classLoader = caller.getClassLoader();
>             final LogContext result = check(classLoader);
>             if (result != null) {
>                 return result;
>             }
>         }
>         return defaultSelector.getLogContext();
>     }
>     private LogContext check(final ClassLoader classLoader) {
>         if (classLoader != null && !logApiClassLoaders.contains(classLoader)) {
>             final LogContext context = contextMap.get(classLoader);
>             if (context != null) {
>                 return context;
>             }
>             if (checkParentClassLoaders) {
>                 return check(classLoader.getParent());
>             }
>         }
>         return null;
>     }
> };
> {code}
> {code:title=Current Version}
> private final PrivilegedAction<LogContext> logContextAction = new PrivilegedAction<LogContext>() {
>     public LogContext run() {
>         final Class<?> callingClass = JDKSpecific.findCallingClass(logApiClassLoaders);
>         return callingClass == null ? defaultSelector.getLogContext() : check(callingClass.getClassLoader());
>     }
>     private LogContext check(final ClassLoader classLoader) {
>         final LogContext context = contextMap.get(classLoader);
>         if (context != null) {
>             return context;
>         }
>         final ClassLoader parent = classLoader.getParent();
>         if (parent != null && checkParentClassLoaders && ! logApiClassLoaders.contains(parent)) {
>             return check(parent);
>         }
>         return defaultSelector.getLogContext();
>     }
> };
> {code}
> The new version only checks the first caller found, then returns the default. The older version checks the callers until it finds a non-null value finally returning the default if no callers were found with associated contexts.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 18 22:34:00 2017
From: issues at jboss.org (Brian Wallis (JIRA))
Date: Mon, 18 Dec 2017 22:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not
 being created
In-Reply-To: <JIRA.12652843.1475249181000@Atlassian.JIRA>
References: <JIRA.12652843.1475249181000@Atlassian.JIRA>
	<JIRA.12652843.1475249181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652843.1475249181000.4246.1513654440300@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506905#comment-13506905 ] 

Brian Wallis commented on WFLY-7247:
------------------------------------

Is it known if this issue is fixed in 11.x? If so it would be useful to note that here (and possibly back in the linked forum threads).

> Wildfly 10 JSESSIONIDSSOs not being created
> -------------------------------------------
>
>                 Key: WFLY-7247
>                 URL: https://issues.jboss.org/browse/WFLY-7247
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: M Wardell
>            Assignee: Jason Greene
>
> Found on wildfly 10.1 and 10.0.  With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism.  Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service.
> Issue in intermittent on startup.  After most startups the JESSSIONIDSSO is reliably generated during login.  After some startups the JSESSIONIDSSO is never created after login.
> Details in the referenced forum thread.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 03:37:00 2017
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Tue, 19 Dec 2017 03:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2190) DMN: Run TCK suite from a
 specified branch within our build
In-Reply-To: <JIRA.12725577.1513672591000@Atlassian.JIRA>
References: <JIRA.12725577.1513672591000@Atlassian.JIRA>
	<JIRA.12725577.1513672591985@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725577.1513672591000.4698.1513672620116@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2190:
-------------------------------------

             Summary: DMN: Run TCK suite from a specified branch within our build
                 Key: DROOLS-2190
                 URL: https://issues.jboss.org/browse/DROOLS-2190
             Project: Drools
          Issue Type: Task
          Components: dmn engine
    Affects Versions: 7.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Tibor Zim?nyi
             Fix For: 7.6.0.Final


Currently we are able to download and run only master branch of DMN TCK git repository. Maven SCM plugin we use contains settings that we can use to run TCK tests from specified branch. These settings should be added to Maven SCM plugin configuration we have in kie-dmn-tck module. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Dec 19 06:15:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 19 Dec 2017 06:15: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.5405.1513682100350@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated HAWKULARQE-214:
--------------------------------------
    Description: 
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.

  was:
https://bugzilla.redhat.com/show_bug.cgi?id=1526791

Remove Middleware Manager from CFME UI:
Menu: Middleware
Control -> Explorer
Cloud Intel -> Reports

Disable Middleware Manager provider in CFME Tests framework.



> [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  Tue Dec 19 06:26:00 2017
From: issues at jboss.org (=?UTF-8?Q?Vlastimil_Eli=C3=A1=C5=A1_=28JIRA=29?=)
Date: Tue, 19 Dec 2017 06:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1366) Cannot access remote KIE
 maven repo - Unauthorized access 401
In-Reply-To: <JIRA.12663022.1479811280000@Atlassian.JIRA>
References: <JIRA.12663022.1479811280000@Atlassian.JIRA>
	<JIRA.12663022.1479811280000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663022.1479811280000.5466.1513682760646@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vlastimil Eli?? deleted DROOLS-1366:
------------------------------------


> Cannot access remote KIE maven repo - Unauthorized access 401
> -------------------------------------------------------------
>
>                 Key: DROOLS-1366
>                 URL: https://issues.jboss.org/browse/DROOLS-1366
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Sambhaji Biradar
>            Assignee: Mario Fusco
>
> Using the latest 6.5 version, we are getting unauthorized access error. From the other posts I see that this issue was resolved in earlier versions but wondering if this issue was introduced again in 6.5. I tried this solution with no success - https://issues.jboss.org/browse/DROOLS-436.
> Could someone help resolving the issue please?
>  
> #NOTE: This is an Aether internal implementation file, its format can be changed without prior notice.
> #Mon Nov 21 19:20:51 EST 2016
> maven-metadata-central.xml.error=Could not transfer metadata com.xxx.xxx.ruleengine\:fraudrules\:1.1-SNAPSHOT/maven-metadata.xml from/to central (http\://repo1.maven.org/maven2/)\: Connect to repo1.maven.org\:80 timed out
> maven-metadata-guvnor-m2-repo.xml.error=Could not transfer metadata com.xxx.xxx.ruleengine\:rules\:1.1-SNAPSHOT/maven-metadata.xml from/to guvnor-m2-repo (http\://10.xxx.77.xxx\:8080/kie-drools-wb/maven2/)\: Unauthorized (401)
> maven-metadata-workbench.xml.lastUpdated=1479774051131
> maven-metadata-guvnor-m2-repo.xml/@default-guvnor-m2-repo-http\://10.xxx.77.xxx\:8080/kie-drools-wb/maven2/.lastUpdated=1479774051096
> maven-metadata-central.xml/@default-central-http\://repo1.maven.org/maven2/.lastUpdated=1479774050359



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Dec 19 08:51:00 2017
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Tue, 19 Dec 2017 08:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2191) Test
 SharedSessionParallelTest.testLongRunningRule2 fails randomly on Kie
 Jenkins
In-Reply-To: <JIRA.12725632.1513691415000@Atlassian.JIRA>
References: <JIRA.12725632.1513691415000@Atlassian.JIRA>
	<JIRA.12725632.1513691415470@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725632.1513691415000.6174.1513691460120@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2191:
-------------------------------------

             Summary: Test SharedSessionParallelTest.testLongRunningRule2 fails randomly on Kie Jenkins
                 Key: DROOLS-2191
                 URL: https://issues.jboss.org/browse/DROOLS-2191
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.6.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Tibor Zim?nyi


The mentioned test fails randomly on Kie Jenkins. It must be investigated. 

https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/drools/281/testReport/junit/org.drools.compiler.integrationtests.concurrency/SharedSessionParallelTest/testLongRunningRule2_Enforced_jitting_true__Serialize_KieBase_false_/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Dec 19 09:10:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 19 Dec 2017 09:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2192) DMN QName regex problem and
 assimilated for function drools:kind
In-Reply-To: <JIRA.12725634.1513692548000@Atlassian.JIRA>
References: <JIRA.12725634.1513692548000@Atlassian.JIRA>
	<JIRA.12725634.1513692548403@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725634.1513692548000.6242.1513692600173@Atlassian.JIRA>

Matteo Mortari created DROOLS-2192:
--------------------------------------

             Summary: DMN QName regex problem and assimilated for function drools:kind
                 Key: DROOLS-2192
                 URL: https://issues.jboss.org/browse/DROOLS-2192
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
            Reporter: Matteo Mortari
            Assignee: Edson Tirelli


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 Dec 19 09:11:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 19 Dec 2017 09:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2192) DMN QName regex problem and
 assimilated for function drools:kind
In-Reply-To: <JIRA.12725634.1513692548000@Atlassian.JIRA>
References: <JIRA.12725634.1513692548000@Atlassian.JIRA>
	<JIRA.12725634.1513692548000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725634.1513692548000.6245.1513692660222@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari reassigned DROOLS-2192:
--------------------------------------

    Assignee: Matteo Mortari  (was: Edson Tirelli)


> DMN QName regex problem and assimilated for function drools:kind
> ----------------------------------------------------------------
>
>                 Key: DROOLS-2192
>                 URL: https://issues.jboss.org/browse/DROOLS-2192
>             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 Dec 19 10:10:02 2017
From: issues at jboss.org (Erich Duda (JIRA))
Date: Tue, 19 Dec 2017 10:10:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9621) Nonintuitive error message
 when for loop is used inside of if/try/batch constructs
In-Reply-To: <JIRA.12725648.1513696167000@Atlassian.JIRA>
References: <JIRA.12725648.1513696167000@Atlassian.JIRA>
	<JIRA.12725648.1513696167797@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725648.1513696167000.6481.1513696202364@Atlassian.JIRA>

Erich Duda created WFLY-9621:
--------------------------------

             Summary: Nonintuitive error message when for loop is used inside of if/try/batch constructs
                 Key: WFLY-9621
                 URL: https://issues.jboss.org/browse/WFLY-9621
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 11.0.0.Final
            Reporter: Erich Duda
            Assignee: Jason Greene


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 Dec 19 10:11:01 2017
From: issues at jboss.org (Erich Duda (JIRA))
Date: Tue, 19 Dec 2017 10:11:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9621) 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.6490.1513696261196@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erich Duda reassigned WFLY-9621:
--------------------------------

    Assignee: Jean-Francois Denise  (was: Jason Greene)


> Nonintuitive error message when for loop is used inside of if/try/batch constructs
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-9621
>                 URL: https://issues.jboss.org/browse/WFLY-9621
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 11.0.0.Final
>            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 Dec 19 10:13:01 2017
From: issues at jboss.org (Martin Mazanek (JIRA))
Date: Tue, 19 Dec 2017 10:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration
 uniqueness enhancements
In-Reply-To: <JIRA.12675329.1486478892000@Atlassian.JIRA>
References: <JIRA.12675329.1486478892000@Atlassian.JIRA>
	<JIRA.12675329.1486478892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675329.1486478892000.6518.1513696381800@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Mazanek reassigned ELY-929:
----------------------------------

    Assignee:     (was: Martin Mazanek)


> AuthenticationConfiguration uniqueness enhancements
> ---------------------------------------------------
>
>                 Key: ELY-929
>                 URL: https://issues.jboss.org/browse/ELY-929
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: David Lloyd
>             Fix For: 1.2.0.Beta12
>
>
> Apply some enhancements to AuthenticationConfiguration uniqueness.
> * Add admonishing JavaDoc to {{useCallbackHandler}} to point out the importance of per-identity uniqueness of the callback handler
> The following also may be possible and useful:
> * Modify the {{AuthenticationConfiguration}} process to capture instances for {{Supplier}}-driven components at the time the configuration is used via the {{AuthenticationContextConfigurationClient}}
> * Add a variation of {{useCallbackHandler}} which accepts a {{Supplier<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 11:08:01 2017
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Tue, 19 Dec 2017 11:08:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9277) Wildfly logs warning
 "WFLYEJB0463: Invalid transaction attribute" for Stateful components with
 CDI lifecycle methods
In-Reply-To: <JIRA.12709330.1504075100000@Atlassian.JIRA>
References: <JIRA.12709330.1504075100000@Atlassian.JIRA>
	<JIRA.12709330.1504075100000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709330.1504075100000.6930.1513699681678@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski closed WFLY-9277.
--------------------------------
    Resolution: Rejected


> Wildfly logs warning "WFLYEJB0463: Invalid transaction attribute" for Stateful components with CDI lifecycle methods
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9277
>                 URL: https://issues.jboss.org/browse/WFLY-9277
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 11.0.0.CR1
>         Environment: WFLY 11.0.0.CR1, JDK8
>            Reporter: Bernhard Hablesreiter
>            Assignee: Tomasz Adamski
>              Labels: cdi, ejb, transaction
>
> Wildlfy logs a warning "WFLYEJB0463: Invalid transaction attribute type REQUIRED on SFSB lifecycle method Method postConstruct() of class class com.test.Test, valid types are REQUIRES_NEW and NOT_SUPPORTED. Method will be treated as NOT_SUPPORTED." for @Stateful-components with CDI lifecycle annotations, even if the Class does not define any Transaction-Attributes:
> {code:java}
> @Named
> @SessionScoped
> @Stateful
> public class Test implements Serializable
> {
> 	private static final long serialVersionUID = -2055975290009863989L;
> 	@PostConstruct
> 	private void postConstruct()
> 	{}
> }
> {code}
> The warning is only created when the @PostConstruct-method is on the class itself and not inherited (which does not make any difference). If the class extends another class, which declares a @PostConstruct-method, the warning does not appear.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 11:20:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Dec 2017 11:20: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.7035.1513700400926@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507185#comment-13507185 ] 

David Lloyd commented on ELY-283:
---------------------------------

There are a number of people we can contact.  I myself keep an OpenJDK checkout for experiments and research; I recommend that for anyone as it might be possible to narrow the problem down to a specific bug.

That said, beyond our own OpenJDK team, the responsible people for GSS in the JDK are to be found on [the OpenJDK security development list|http://mail.openjdk.java.net/mailman/listinfo/security-dev].

> 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: openjdk-patch-native-mechs.patch
>
>
> 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 Dec 19 11:23:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 11:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not
 being created
In-Reply-To: <JIRA.12652843.1475249181000@Atlassian.JIRA>
References: <JIRA.12652843.1475249181000@Atlassian.JIRA>
	<JIRA.12652843.1475249181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652843.1475249181000.7064.1513700580921@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-7247:
--------------------------------------

    Assignee: Stuart Douglas  (was: Jason Greene)


> Wildfly 10 JSESSIONIDSSOs not being created
> -------------------------------------------
>
>                 Key: WFLY-7247
>                 URL: https://issues.jboss.org/browse/WFLY-7247
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: M Wardell
>            Assignee: Stuart Douglas
>
> Found on wildfly 10.1 and 10.0.  With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism.  Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service.
> Issue in intermittent on startup.  After most startups the JESSSIONIDSSO is reliably generated during login.  After some startups the JSESSIONIDSSO is never created after login.
> Details in the referenced forum thread.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 11:25:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Dec 2017 11:25: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.7071.1513700700227@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507187#comment-13507187 ] 

David Lloyd commented on ELY-283:
---------------------------------

Do you have the trace output that immediately precedes the JVM crash?  That might help find the offending native code.

> 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: openjdk-patch-native-mechs.patch
>
>
> 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 Dec 19 11:48:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 11:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9622) Eliminate uses of
	ModelNode.resolve()
In-Reply-To: <JIRA.12725662.1513702020000@Atlassian.JIRA>
References: <JIRA.12725662.1513702020000@Atlassian.JIRA>
	<JIRA.12725662.1513702020954@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725662.1513702020000.7170.1513702080134@Atlassian.JIRA>

Brian Stansberry created WFLY-9622:
--------------------------------------

             Summary: Eliminate uses of ModelNode.resolve()
                 Key: WFLY-9622
                 URL: https://issues.jboss.org/browse/WFLY-9622
             Project: WildFly
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


Code inspection shows there are 23 uses of ModelNode.resolve() in WildFly's own code base, 12 in production code and 11 in test code. We should eliminate these, as WildFly's expression resolution is more complex than the ModelNode.resolve() contract, including vault support for which its' hard to imagine us wanting support in DMR itself. So these uses should switch to resolution from the OperationContext or, if that's not feasible, e.g. in test code, use something like ExpressionResolver.TEST_RESOLVER.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 11:48:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 11:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9623) Eliminate uses of
	ModelNode.resolve()
In-Reply-To: <JIRA.12725663.1513702069000@Atlassian.JIRA>
References: <JIRA.12725663.1513702069000@Atlassian.JIRA>
	<JIRA.12725663.1513702069905@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725663.1513702069000.7172.1513702080219@Atlassian.JIRA>

Brian Stansberry created WFLY-9623:
--------------------------------------

             Summary: Eliminate uses of ModelNode.resolve()
                 Key: WFLY-9623
                 URL: https://issues.jboss.org/browse/WFLY-9623
             Project: WildFly
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


Code inspection shows there are 23 uses of ModelNode.resolve() in WildFly's own code base, 12 in production code and 11 in test code. We should eliminate these, as WildFly's expression resolution is more complex than the ModelNode.resolve() contract, including vault support for which its' hard to imagine us wanting support in DMR itself. So these uses should switch to resolution from the OperationContext or, if that's not feasible, e.g. in test code, use something like ExpressionResolver.TEST_RESOLVER.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 11:50:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 11:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3465) Eliminate uses of
	ModelNode.resolve()
In-Reply-To: <JIRA.12725663.1513702070000@Atlassian.JIRA>
References: <JIRA.12725663.1513702070000@Atlassian.JIRA>
	<JIRA.12725663.1513702070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725663.1513702070000.7175.1513702200087@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-9623 to WFCORE-3465:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-3465  (was: WFLY-9623)
    Component/s: Domain Management
                     (was: Domain Management)


> Eliminate uses of ModelNode.resolve()
> -------------------------------------
>
>                 Key: WFCORE-3465
>                 URL: https://issues.jboss.org/browse/WFCORE-3465
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> Code inspection shows there are 23 uses of ModelNode.resolve() in WildFly's own code base, 12 in production code and 11 in test code. We should eliminate these, as WildFly's expression resolution is more complex than the ModelNode.resolve() contract, including vault support for which its' hard to imagine us wanting support in DMR itself. So these uses should switch to resolution from the OperationContext or, if that's not feasible, e.g. in test code, use something like ExpressionResolver.TEST_RESOLVER.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 12:06:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 12:06:00 -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.7214.1513703160282@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507206#comment-13507206 ] 

Brian Stansberry commented on WFCORE-2336:
------------------------------------------

It's fairly likely I'll defer this to WF 13 (presumably WF Core 5) as the deprecation is still fairly recent in terms of .Final code.

> 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.Alpha6
>
>
> 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  Tue Dec 19 13:24:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Dec 2017 13:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707797000@Atlassian.JIRA>
References: <JIRA.12725669.1513707797000@Atlassian.JIRA>
	<JIRA.12725669.1513707797963@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707797000.7345.1513707840464@Atlassian.JIRA>

David Lloyd created LOGTOOL-132:
-----------------------------------

             Summary: 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 Dec 19 13:25:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Dec 2017 13:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-129) Support loading
 low-metaspace bundles/loggers
In-Reply-To: <JIRA.12725670.1513707893000@Atlassian.JIRA>
References: <JIRA.12725670.1513707893000@Atlassian.JIRA>
	<JIRA.12725670.1513707893668@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725670.1513707893000.7349.1513707900280@Atlassian.JIRA>

David Lloyd created JBLOGGING-129:
-------------------------------------

             Summary: Support loading low-metaspace bundles/loggers
                 Key: JBLOGGING-129
                 URL: https://issues.jboss.org/browse/JBLOGGING-129
             Project: JBoss Logging
          Issue Type: Enhancement
            Reporter: David Lloyd
            Priority: Critical


Allow loading of low-metaspace logger classes that are generated by the logging tool.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 13:32:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Dec 2017 13:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration
 uniqueness enhancements
In-Reply-To: <JIRA.12675329.1486478892000@Atlassian.JIRA>
References: <JIRA.12675329.1486478892000@Atlassian.JIRA>
	<JIRA.12675329.1486478892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675329.1486478892000.7353.1513708320301@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507221#comment-13507221 ] 

David Lloyd commented on ELY-929:
---------------------------------

The purpose is so that new instances of the callback handler can be instantiated for each outbound authentication usage, instead of using one callback handler which is shared for every authentication configuration.

However, this relies on some fragile semantics on behalf of the authentication context client: do we construct a new callback handler on every authentication attempt, or do we keep them around to be reused for all authentications for the same session or endpoint?  What semantics can the user expect from callback handlers constructed in this way?  These questions need to be answered definitively before we can do this.

Also, we have to consider equals/hashCode behavior.  In order to reliably cache connections, protocol implementors need the ability to know if a second usage is using the same configuration as a first usage, to know if a separate authentication must be performed or if an existing authentication can be reused.  Using Supplier invites lambdas, which have problematic equals/hashCode behavior, potentially breaking this contract and causing many unnecessary authentications to be performed.


> AuthenticationConfiguration uniqueness enhancements
> ---------------------------------------------------
>
>                 Key: ELY-929
>                 URL: https://issues.jboss.org/browse/ELY-929
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: David Lloyd
>             Fix For: 1.2.0.Beta12
>
>
> Apply some enhancements to AuthenticationConfiguration uniqueness.
> * Add admonishing JavaDoc to {{useCallbackHandler}} to point out the importance of per-identity uniqueness of the callback handler
> The following also may be possible and useful:
> * Modify the {{AuthenticationConfiguration}} process to capture instances for {{Supplier}}-driven components at the time the configuration is used via the {{AuthenticationContextConfigurationClient}}
> * Add a variation of {{useCallbackHandler}} which accepts a {{Supplier<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 13:45:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 19 Dec 2017 13:45: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.7414.1513709100300@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2182.
---------------------------------
    Resolution: Cannot Reproduce Bug


I definitively cannot reproduce the NPE you reported. If you have a reproducer feel free to attach it to this ticket and reopen it.

> 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 Dec 19 15:20:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 19 Dec 2017 15:20: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.7573.1513714800713@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507250#comment-13507250 ] 

Jan Kalina commented on ELY-283:
--------------------------------

[~dmlloyd] By traces the crash occurs in GSSLibStub.c during call acceptSecContext:
{code}
  major =
    (*ftab->acceptSecContext)(&minor, &contextHdl, credHdl,
                           &inToken, cb, &srcName, &aMech, &outToken,
                           &aFlags, &aTime, &delCred);
{code}
(to be sure I have placed TRACE directly before and after - yet before deleteGSSCB/resetGSSBuffer - the crash occures directly in acceptSecContext)
{code}
21:08:34,181 INFO  [stdout] (management I/O-2) Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt false ticketCache is null isInitiator false KeyTab is /home/jkalina/work/tutorial-kerberos/kerberos-using-apacheds/remote.keytab refreshKrb5Config is false principal is remote/localhost at JBOSS.ORG tryFirstPass is false useFirstPass is false storePass is false clearPass is false
21:08:34,185 INFO  [stdout] (management I/O-2) principal is remote/localhost at JBOSS.ORG
21:08:34,186 INFO  [stdout] (management I/O-2) Will use keytab
21:08:34,186 INFO  [stdout] (management I/O-2) Commit Succeeded 
21:08:34,186 INFO  [stdout] (management I/O-2) 
21:08:34,191 INFO  [stdout] (management I/O-2) SunNativeGSS: Created GSSLibStub for mech 1.2.840.113554.1.2.2
[GSSLibStub_importName]
[GSSLibStub_importName] 139984261540048
[GSSLibStub_displayName] 139984261540048
21:08:34,194 INFO  [stdout] (management I/O-2) SunNativeGSS: Imported remote/localhost at JBOSS.ORG w/ type 1.2.840.113554.1.2.1.1
21:08:34,207 INFO  [stdout] (management I/O-2) Search Subject for Kerberos V5 ACCEPT cred (remote/localhost at JBOSS.ORG, sun.security.jgss.wrapper.GSSCredElement)
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=139984261540048, usage=2
[GSSLibStub_acquireCred] [!JK1!] major=0 minor=0
[GSSLibStub_acquireCred] pCred=139984261571568
[GSSLibStub_acquireCred] [!JK2!] major=0 minor=0
21:08:34,244 INFO  [stdout] (management task-1) SunNativeGSS: Precomputed mechToken length: 500
21:08:34,245 INFO  [stdout] (management task-1) SunNativeGSS: Complete Token length: 515
21:08:34,245 INFO  [stdout] (management task-1) SunNativeGSS: acceptSecContext=> inToken len=515
[GSSLibStub_acceptContext]
[GSSLibStub_acceptContext] before2: pCred=139984261571568, pContext=0
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f51050212b2, pid=12158, tid=12329
#
# JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-adhoc.jkalina.9dev)
# Java VM: OpenJDK 64-Bit Server VM (9-internal+0-adhoc.jkalina.9dev, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [libc.so.6+0x932b2]  cfree+0x32
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e" (or dumping to /home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/core.12158)
#
# An error report file with more information is saved as:
# /home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/hs_err_pid12158.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
bin/standalone.sh: line 311: 12158 Aborted                 (core dumped) "java" -D"[Standalone]" -server -Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.jgss.lib=/usr/lib64/libgssapi_krb5.so.2.2 -Dsun.security.jgss.native=true -Dsun.security.nativegss.debug=true -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n "-Dorg.jboss.boot.log.file=/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/standalone/log/server.log" "-Dlogging.configuration=file:/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/standalone/configuration/logging.properties" -jar "/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/jboss-modules.jar" -mp "/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/modules" org.jboss.as.standalone -Djboss.home.dir="/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT" -Djboss.server.base.dir="/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/standalone"
{code}

> 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: openjdk-patch-native-mechs.patch
>
>
> 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 Dec 19 15:36:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Dec 2017 15:36: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.7597.1513715760409@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507253#comment-13507253 ] 

David Lloyd commented on ELY-283:
---------------------------------

That implies that the invalid free is happening inside the GSS library's gss_accept_sec_context function ({{*ftab}} contains a list of functions that are loaded via {{dlsym}} from the target GSS library).  It could be a bug in the library, or a parameter that has an invalid value, among other things.  You'd have to attach a debugger to know for sure, but that likely will not work unless you have a {{fastdebug}} OpenJDK build on hand...

> 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: openjdk-patch-native-mechs.patch
>
>
> 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 Dec 19 16:45:01 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 19 Dec 2017 16:45:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not
 being created
In-Reply-To: <JIRA.12652843.1475249181000@Atlassian.JIRA>
References: <JIRA.12652843.1475249181000@Atlassian.JIRA>
	<JIRA.12652843.1475249181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652843.1475249181000.7664.1513719901676@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-7247.
----------------------------------
    Resolution: Duplicate Issue


Fixed under WFLY-8774

> Wildfly 10 JSESSIONIDSSOs not being created
> -------------------------------------------
>
>                 Key: WFLY-7247
>                 URL: https://issues.jboss.org/browse/WFLY-7247
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: M Wardell
>            Assignee: Stuart Douglas
>
> Found on wildfly 10.1 and 10.0.  With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism.  Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service.
> Issue in intermittent on startup.  After most startups the JESSSIONIDSSO is reliably generated during login.  After some startups the JSESSIONIDSSO is never created after login.
> Details in the referenced forum thread.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 17:35:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 17:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9539) wsconsume.sh does not support
 the -secmgr setting properly
In-Reply-To: <JIRA.12720169.1510191077000@Atlassian.JIRA>
References: <JIRA.12720169.1510191077000@Atlassian.JIRA>
	<JIRA.12720169.1510191077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720169.1510191077000.7706.1513722900567@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-9539:
--------------------------------------

    Fix Version/s: 12.0.0.Alpha1
         Assignee: R Searls  (was: Tomaz Cerar)
       Resolution: Done


> wsconsume.sh does not support the -secmgr setting properly
> ----------------------------------------------------------
>
>                 Key: WFLY-9539
>                 URL: https://issues.jboss.org/browse/WFLY-9539
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts, Web Services
>    Affects Versions: 10.0.0.Final
>            Reporter: R Searls
>            Assignee: R Searls
>             Fix For: 12.0.0.Alpha1
>
>
> wsconsume.sh, and wsconsume.bat does not properly support the -secmgr flag in the
> generated command.  Changes to jboss-module.jar requires the -secmgr flag be positioned
> immediately after the  jboss-module.jar declaration.
> {code:java}
> eval \"$JAVA\" $JAVA_OPTS \
>     -classpath \""$JBOSS_CLASSPATH"\" \
>     org.jboss.modules.Main \
>     -secmgr \
>     -mp \""$JBOSS_HOME"/modules\" \
>     org.jboss.ws.tools.wsconsume \
>     '"$@"'
> {code}
> This value is pass to this utility via the JAVA_OPTS env variable.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 17:35:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 17:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9538) wsprovide.sh does not support
 the -secmgr setting properly
In-Reply-To: <JIRA.12720167.1510190421000@Atlassian.JIRA>
References: <JIRA.12720167.1510190421000@Atlassian.JIRA>
	<JIRA.12720167.1510190421000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720167.1510190421000.7710.1513722900849@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-9538:
--------------------------------------

    Assignee: R Searls  (was: Tomaz Cerar)


> wsprovide.sh does not support the -secmgr setting properly
> ----------------------------------------------------------
>
>                 Key: WFLY-9538
>                 URL: https://issues.jboss.org/browse/WFLY-9538
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 10.0.0.Final
>            Reporter: R Searls
>            Assignee: R Searls
>
> wsprovide.sh, wsprovide.bat  does not generate the cmd with the -secmgr flag in the
> proper position.  Changes to jboss-module.jar requires -segmgr to reside just after
> the jboss-module.jar reference like this.
> {code:java}
> eval \"$JAVA\" $JAVA_OPTS \
>     -jar \""$JBOSS_HOME"/jboss-modules.jar\" \
>     *-secmgr \ *                                                                  
>     -mp \""$JBOSS_HOME"/modules\" \
>     org.jboss.ws.tools.wsprovide \
>     '"$@"'
> {code}
> Current the old style and this new style value is passed in via the JAVA_OPTS env var.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 18:18:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Dec 2017 18:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3466) Add reflection option to
 org.jboss.as.controller.parsing.ExtensionParsingContext
In-Reply-To: <JIRA.12725676.1513725440000@Atlassian.JIRA>
References: <JIRA.12725676.1513725440000@Atlassian.JIRA>
	<JIRA.12725676.1513725440714@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725676.1513725440000.7724.1513725480119@Atlassian.JIRA>

David Lloyd created WFCORE-3466:
-----------------------------------

             Summary: Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext
                 Key: WFCORE-3466
                 URL: https://issues.jboss.org/browse/WFCORE-3466
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: David Lloyd


As a way to combat aggressive class initialization, WFCORE-1841 added a variant method to {{ExtensionParsingContext}} which allowed a supplier of a parser to be provided.

This has resulted in an explosion of lambda usage; around 150 calls to this method exist, most of which supply constructor references as the {{Supplier}} argument.

We can theoretically save considerable metaspace by doing one of the following:

* Add a variation of the method which accepts a {{Class}} instead of a {{Supplier}}; it uses {{Class.newInstance()}} or {{Class.getConstructor().newInstance()}} to instantiate the parser on demand
* Create a reflective {{Supplier}} implementation which, given a {{Class}}, uses it in this way to construct instances

Performance impact should be very minimal, as the overhead of calling a constructor is less than that of compiling a method reference, and the overhead in metaspace is nearly non-existent in comparison.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 18:26:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 18:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3466) Add reflection option to
 org.jboss.as.controller.parsing.ExtensionParsingContext
In-Reply-To: <JIRA.12725676.1513725441000@Atlassian.JIRA>
References: <JIRA.12725676.1513725441000@Atlassian.JIRA>
	<JIRA.12725676.1513725441000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725676.1513725441000.7729.1513725960091@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507274#comment-13507274 ] 

Brian Stansberry commented on WFCORE-3466:
------------------------------------------

Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of the parser impl Class, and only load it if we actually encounter the namespace that demands it. 

> Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-3466
>                 URL: https://issues.jboss.org/browse/WFCORE-3466
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: David Lloyd
>
> As a way to combat aggressive class initialization, WFCORE-1841 added a variant method to {{ExtensionParsingContext}} which allowed a supplier of a parser to be provided.
> This has resulted in an explosion of lambda usage; around 150 calls to this method exist, most of which supply constructor references as the {{Supplier}} argument.
> We can theoretically save considerable metaspace by doing one of the following:
> * Add a variation of the method which accepts a {{Class}} instead of a {{Supplier}}; it uses {{Class.newInstance()}} or {{Class.getConstructor().newInstance()}} to instantiate the parser on demand
> * Create a reflective {{Supplier}} implementation which, given a {{Class}}, uses it in this way to construct instances
> Performance impact should be very minimal, as the overhead of calling a constructor is less than that of compiling a method reference, and the overhead in metaspace is nearly non-existent in comparison.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 18:29:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 18:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3466) Add reflection option to
 org.jboss.as.controller.parsing.ExtensionParsingContext
In-Reply-To: <JIRA.12725676.1513725441000@Atlassian.JIRA>
References: <JIRA.12725676.1513725441000@Atlassian.JIRA>
	<JIRA.12725676.1513725441000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725676.1513725441000.7732.1513726140164@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507274#comment-13507274 ] 

Brian Stansberry edited comment on WFCORE-3466 at 12/19/17 6:28 PM:
--------------------------------------------------------------------

Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of the parser impl Class, and only load it if we actually encounter the namespace that demands it. 

Exception being the current parser, which we often want to load during Extension.initializeParsers, since in most subsystems that means the subsystem static initialization stuff (AttributeDefinition etc) gets run during the concurrent part of boot.


was (Author: brian.stansberry):
Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of the parser impl Class, and only load it if we actually encounter the namespace that demands it. 

> Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-3466
>                 URL: https://issues.jboss.org/browse/WFCORE-3466
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: David Lloyd
>
> As a way to combat aggressive class initialization, WFCORE-1841 added a variant method to {{ExtensionParsingContext}} which allowed a supplier of a parser to be provided.
> This has resulted in an explosion of lambda usage; around 150 calls to this method exist, most of which supply constructor references as the {{Supplier}} argument.
> We can theoretically save considerable metaspace by doing one of the following:
> * Add a variation of the method which accepts a {{Class}} instead of a {{Supplier}}; it uses {{Class.newInstance()}} or {{Class.getConstructor().newInstance()}} to instantiate the parser on demand
> * Create a reflective {{Supplier}} implementation which, given a {{Class}}, uses it in this way to construct instances
> Performance impact should be very minimal, as the overhead of calling a constructor is less than that of compiling a method reference, and the overhead in metaspace is nearly non-existent in comparison.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 19:57:00 2017
From: issues at jboss.org (Lance Leverich (JIRA))
Date: Tue, 19 Dec 2017 19:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2193) MVEL Dialect cannot find
 the FH when using modify on a DataSource
In-Reply-To: <JIRA.12725677.1513731380000@Atlassian.JIRA>
References: <JIRA.12725677.1513731380000@Atlassian.JIRA>
	<JIRA.12725677.1513731380912@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725677.1513731380000.7792.1513731420165@Atlassian.JIRA>

Lance Leverich created DROOLS-2193:
--------------------------------------

             Summary: MVEL Dialect cannot find the FH when using modify on a DataSource
                 Key: DROOLS-2193
                 URL: https://issues.jboss.org/browse/DROOLS-2193
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Lance Leverich
            Assignee: Mario Fusco


Attempting to use _modify_ on a fact that is retrieved from a DataSource will sometimes cause an error that reads:

{{Update error: handle not found for object: ...}}

Using dialect "java" fixes the issue.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 20:03:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 20:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3467) Require existence of the
 AttributeDefinition in AbstractWriteAttributeHandler
In-Reply-To: <JIRA.12725678.1513731776000@Atlassian.JIRA>
References: <JIRA.12725678.1513731776000@Atlassian.JIRA>
	<JIRA.12725678.1513731776947@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725678.1513731776000.7794.1513731780091@Atlassian.JIRA>

Brian Stansberry created WFCORE-3467:
----------------------------------------

             Summary: Require existence of the AttributeDefinition in AbstractWriteAttributeHandler
                 Key: WFCORE-3467
                 URL: https://issues.jboss.org/browse/WFCORE-3467
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


AbstractWriteAttributeHandler has logic to deal with the case where it has no reference to an AttributeDefinition for the relevant attribute. This is compatibility code from the days before AttributeDefinition.  But using AD has been the standard for many years now, so lets drop this and fail if there is no AD.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 19 22:10:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 19 Dec 2017 22:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3468) Get rid of multiple
 deployment-scanner AbstractWriteAttributeHandler subclasses;
 use a single class
In-Reply-To: <JIRA.12725680.1513739371000@Atlassian.JIRA>
References: <JIRA.12725680.1513739371000@Atlassian.JIRA>
	<JIRA.12725680.1513739371235@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725680.1513739371000.7918.1513739400222@Atlassian.JIRA>

Brian Stansberry created WFCORE-3468:
----------------------------------------

             Summary: Get rid of multiple deployment-scanner AbstractWriteAttributeHandler subclasses; use a single class
                 Key: WFCORE-3468
                 URL: https://issues.jboss.org/browse/WFCORE-3468
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Deployment Scanner
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


The deployment-scanner has a bunch of write-attribute handlers that are basically just 1 or 2 line implementations of a method in a superclass. Just put it all in the superclass.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 04:58:00 2017
From: issues at jboss.org (Andrej Kolontai (JIRA))
Date: Wed, 20 Dec 2017 04:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9624) Improper handling of
 application exceptions on asynchronous ejb invocations
In-Reply-To: <JIRA.12725690.1513763860000@Atlassian.JIRA>
References: <JIRA.12725690.1513763860000@Atlassian.JIRA>
	<JIRA.12725690.1513763860090@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725690.1513763860000.8615.1513763880408@Atlassian.JIRA>

Andrej Kolontai created WFLY-9624:
-------------------------------------

             Summary: Improper handling of application exceptions on asynchronous ejb invocations
                 Key: WFLY-9624
                 URL: https://issues.jboss.org/browse/WFLY-9624
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 11.0.0.Final
            Reporter: Andrej Kolontai


If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.

This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final. 

I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.

The isDone Method is implemented like this:

{{
    @Override
    public boolean isDone() {
        return status == ST_DONE;
    }
}}

But status can be one of:
{{
    private static final int ST_RUNNING = 0;
    private static final int ST_DONE = 1;
    private static final int ST_CANCELLED = 2;
    private static final int ST_FAILED = 3;
}}

And and exception sets the status to 

{{
    private synchronized void setFailed(final Exception e) {
        this.failed = e;
        status = ST_FAILED;
        done();
    }
}}

So it's pretty obvious. 

The javadoc on java.util.concurrent.Future states:

{quote}
Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
{quote}

So the isDone() method should  look more like this:
{{
    @Override
    public boolean isDone() {
        return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
    }
}}

In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
* cancel()
* setResult(...) and
* setFailed(...)





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 05:00:00 2017
From: issues at jboss.org (Andrej Kolontai (JIRA))
Date: Wed, 20 Dec 2017 05:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9624) Improper handling of
 application exceptions on asynchronous ejb invocations
In-Reply-To: <JIRA.12725690.1513763860000@Atlassian.JIRA>
References: <JIRA.12725690.1513763860000@Atlassian.JIRA>
	<JIRA.12725690.1513763860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725690.1513763860000.8621.1513764000610@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrej Kolontai updated WFLY-9624:
----------------------------------
    Description: 
If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.

This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final. 

I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.

The isDone Method is implemented like this:

    {{@Override
    public boolean isDone() {
        return status == ST_DONE;
    }}}

But status can be one of:
{{
    private static final int ST_RUNNING = 0;
    private static final int ST_DONE = 1;
    private static final int ST_CANCELLED = 2;
    private static final int ST_FAILED = 3;
}}

And and exception sets the status to 

{{
    private synchronized void setFailed(final Exception e) {
        this.failed = e;
        status = ST_FAILED;
        done();
    }
}}

So it's pretty obvious. 

The javadoc on java.util.concurrent.Future states:

{quote}
Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
{quote}

So the isDone() method should  look more like this:
{{
    @Override
    public boolean isDone() {
        return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
    }
}}

In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
* cancel()
* setResult(...) and
* setFailed(...)



  was:
If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.

This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final. 

I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.

The isDone Method is implemented like this:

{{
    @Override
    public boolean isDone() {
        return status == ST_DONE;
    }
}}

But status can be one of:
{{
    private static final int ST_RUNNING = 0;
    private static final int ST_DONE = 1;
    private static final int ST_CANCELLED = 2;
    private static final int ST_FAILED = 3;
}}

And and exception sets the status to 

{{
    private synchronized void setFailed(final Exception e) {
        this.failed = e;
        status = ST_FAILED;
        done();
    }
}}

So it's pretty obvious. 

The javadoc on java.util.concurrent.Future states:

{quote}
Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
{quote}

So the isDone() method should  look more like this:
{{
    @Override
    public boolean isDone() {
        return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
    }
}}

In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
* cancel()
* setResult(...) and
* setFailed(...)





> Improper handling of application exceptions on asynchronous ejb invocations
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-9624
>                 URL: https://issues.jboss.org/browse/WFLY-9624
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 11.0.0.Final
>            Reporter: Andrej Kolontai
>
> If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
> This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final. 
> I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
> The isDone Method is implemented like this:
>     {{@Override
>     public boolean isDone() {
>         return status == ST_DONE;
>     }}}
> But status can be one of:
> {{
>     private static final int ST_RUNNING = 0;
>     private static final int ST_DONE = 1;
>     private static final int ST_CANCELLED = 2;
>     private static final int ST_FAILED = 3;
> }}
> And and exception sets the status to 
> {{
>     private synchronized void setFailed(final Exception e) {
>         this.failed = e;
>         status = ST_FAILED;
>         done();
>     }
> }}
> So it's pretty obvious. 
> The javadoc on java.util.concurrent.Future states:
> {quote}
> Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
> {quote}
> So the isDone() method should  look more like this:
> {{
>     @Override
>     public boolean isDone() {
>         return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
>     }
> }}
> In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
> * cancel()
> * setResult(...) and
> * setFailed(...)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 05:38:00 2017
From: issues at jboss.org (Roland Brackmann (JIRA))
Date: Wed, 20 Dec 2017 05:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-139) Add maxBackupIndex to
 periodic-rotating-file-handlers
In-Reply-To: <JIRA.12633217.1466065997000@Atlassian.JIRA>
References: <JIRA.12633217.1466065997000@Atlassian.JIRA>
	<JIRA.12633217.1466065997000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633217.1466065997000.8791.1513766280486@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGMGR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507387#comment-13507387 ] 

Roland Brackmann commented on LOGMGR-139:
-----------------------------------------

Hi [~jamezp] for the record, this is a feature we were looking for aswell and opened this ticket hoping for an RFE :
https://access.redhat.com/support/cases/#/case/01989912
Our use case : being in docker and obliged to write on the filesystem for logging (not the container way of logging) it would be even more any container to spin up a cron job in the background...

> Add maxBackupIndex to periodic-rotating-file-handlers
> -----------------------------------------------------
>
>                 Key: LOGMGR-139
>                 URL: https://issues.jboss.org/browse/LOGMGR-139
>             Project: JBoss Log Manager
>          Issue Type: Enhancement
>            Reporter: R?my Garrigue
>            Priority: Minor
>
> That's all in the title. 
> We would like to have a daily log, keeping 15 days of log. Actually there's no way to do that except maybe custom handler which we can't get to work. That'ld be far easier if there was the same maxBackupIndex  option as in size rotating handler.
> Regards, 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 05:48:00 2017
From: issues at jboss.org (Andrej Kolontai (JIRA))
Date: Wed, 20 Dec 2017 05:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9624) Improper handling of
 application exceptions on asynchronous ejb invocations
In-Reply-To: <JIRA.12725690.1513763860000@Atlassian.JIRA>
References: <JIRA.12725690.1513763860000@Atlassian.JIRA>
	<JIRA.12725690.1513763860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725690.1513763860000.8889.1513766880810@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrej Kolontai updated WFLY-9624:
----------------------------------
    Steps to Reproduce: 
Create the following ejb:
{noformat}
@Singleton
public class AsyncBean {

	@Asynchronous
	public Future<Void> doSomeStuff() throws MyException {
		throw new MyException();
	}
}
{noformat}

Call ths bean and poll the result via isDone(). It will never return true.

On wildfly 10, it would immidiatly return true.

  was:
Create the following ejb:
{{
@Singleton
public class AsyncBean {

	@Asynchronous
	public Future<Void> doSomeStuff() throws MyException {
		throw new MyException();
	}
}
}}

Call ths bean and poll the result via isDone(). It will never return true.

On wildfly 10, it would immidiatly return true.



> Improper handling of application exceptions on asynchronous ejb invocations
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-9624
>                 URL: https://issues.jboss.org/browse/WFLY-9624
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 11.0.0.Final
>            Reporter: Andrej Kolontai
>
> If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
> This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final. 
> I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
> The isDone Method is implemented like this:
>     {{@Override
>     public boolean isDone() {
>         return status == ST_DONE;
>     }}}
> But status can be one of:
> {{
>     private static final int ST_RUNNING = 0;
>     private static final int ST_DONE = 1;
>     private static final int ST_CANCELLED = 2;
>     private static final int ST_FAILED = 3;
> }}
> And and exception sets the status to 
> {{
>     private synchronized void setFailed(final Exception e) {
>         this.failed = e;
>         status = ST_FAILED;
>         done();
>     }
> }}
> So it's pretty obvious. 
> The javadoc on java.util.concurrent.Future states:
> {quote}
> Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
> {quote}
> So the isDone() method should  look more like this:
> {{
>     @Override
>     public boolean isDone() {
>         return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
>     }
> }}
> In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
> * cancel()
> * setResult(...) and
> * setFailed(...)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 05:49:00 2017
From: issues at jboss.org (Andrej Kolontai (JIRA))
Date: Wed, 20 Dec 2017 05:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9624) Improper handling of
 application exceptions on asynchronous ejb invocations
In-Reply-To: <JIRA.12725690.1513763860000@Atlassian.JIRA>
References: <JIRA.12725690.1513763860000@Atlassian.JIRA>
	<JIRA.12725690.1513763860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725690.1513763860000.8898.1513766940350@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrej Kolontai updated WFLY-9624:
----------------------------------
    Description: 
If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.

This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final. 

I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.

The isDone Method is implemented like this:

{noformat}
    @Override
    public boolean isDone() {
        return status == ST_DONE;
    }
{noformat}

But status can be one of:
{noformat}
    private static final int ST_RUNNING = 0;
    private static final int ST_DONE = 1;
    private static final int ST_CANCELLED = 2;
    private static final int ST_FAILED = 3;
{noformat}

And and exception sets the status to 

{noformat}
    private synchronized void setFailed(final Exception e) {
        this.failed = e;
        status = ST_FAILED;
        done();
    }
{noformat}

So it's pretty obvious. 

The javadoc on java.util.concurrent.Future states:

{quote}
Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
{quote}

So the isDone() method should  look more like this:
{noformat}
    @Override
    public boolean isDone() {
        return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
    }
{noformat}

In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
* cancel()
* setResult(...) and
* setFailed(...)



  was:
If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.

This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final. 

I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.

The isDone Method is implemented like this:

    {{@Override
    public boolean isDone() {
        return status == ST_DONE;
    }}}

But status can be one of:
{{
    private static final int ST_RUNNING = 0;
    private static final int ST_DONE = 1;
    private static final int ST_CANCELLED = 2;
    private static final int ST_FAILED = 3;
}}

And and exception sets the status to 

{{
    private synchronized void setFailed(final Exception e) {
        this.failed = e;
        status = ST_FAILED;
        done();
    }
}}

So it's pretty obvious. 

The javadoc on java.util.concurrent.Future states:

{quote}
Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
{quote}

So the isDone() method should  look more like this:
{{
    @Override
    public boolean isDone() {
        return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
    }
}}

In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
* cancel()
* setResult(...) and
* setFailed(...)





> Improper handling of application exceptions on asynchronous ejb invocations
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-9624
>                 URL: https://issues.jboss.org/browse/WFLY-9624
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 11.0.0.Final
>            Reporter: Andrej Kolontai
>
> If an asynchronous invocation of an ejb method throws an application exception (declared exception) then the returned future will always return false on isDone(). That means: the client will never know that the operation has finished (unscuccessfully) unless get() is called which would rethrow the original exception.
> This behavior has changed from wildfly 10.1.0.Final to 11.0.0.Final. 
> I pretty sure that the problem is in org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.
> The isDone Method is implemented like this:
> {noformat}
>     @Override
>     public boolean isDone() {
>         return status == ST_DONE;
>     }
> {noformat}
> But status can be one of:
> {noformat}
>     private static final int ST_RUNNING = 0;
>     private static final int ST_DONE = 1;
>     private static final int ST_CANCELLED = 2;
>     private static final int ST_FAILED = 3;
> {noformat}
> And and exception sets the status to 
> {noformat}
>     private synchronized void setFailed(final Exception e) {
>         this.failed = e;
>         status = ST_FAILED;
>         done();
>     }
> {noformat}
> So it's pretty obvious. 
> The javadoc on java.util.concurrent.Future states:
> {quote}
> Completion may be due to normal termination, an exception, or cancellation -- in all of these cases, this method will return true.
> {quote}
> So the isDone() method should  look more like this:
> {noformat}
>     @Override
>     public boolean isDone() {
>         return status == ST_DONE || status == ST_FAILED || status == ST_CANCELLED;
>     }
> {noformat}
> In wildfly 10, there was a single boolean variable "done" which was set to true in all three cases:
> * cancel()
> * setResult(...) and
> * setFailed(...)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 07:01:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 20 Dec 2017 07:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9625) Exception on Weld during
 inicialization of CDI/EJB bean on IBM JDK
In-Reply-To: <JIRA.12725702.1513771221000@Atlassian.JIRA>
References: <JIRA.12725702.1513771221000@Atlassian.JIRA>
	<JIRA.12725702.1513771221687@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725702.1513771221000.9245.1513771260181@Atlassian.JIRA>

Marek Kopeck? created WFLY-9625:
-----------------------------------

             Summary: Exception on Weld during inicialization of CDI/EJB bean on IBM JDK
                 Key: WFLY-9625
                 URL: https://issues.jboss.org/browse/WFLY-9625
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld
            Reporter: Marek Kopeck?
            Assignee: Martin Kouba
            Priority: Blocker


*Description of problem:*
Exception on Weld during inicialization of CDI/EJB bean on IBM JDK

Example of beans:
{code:java}
@RequestScoped
public class LoggingBean {
    static {
        System.out.println("something");
    }
}
{code}
{code:java}
@Singleton
@Startup
public class LoggingBean {
    static {
        System.out.println("something");
    }
}
{code}


*How reproducible:*
Always on IBM JDK

*Steps to Reproduce:*
# Deploy deployment with beans from description

*Actual results:*
CDI bean:
{noformat}

12:49:05,070 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /home/mkopecky/git/wfly.05/standalone/data/content/f8/f08bc0eb9dd3893743634459d1218cdbfeb4ac/content
12:49:05,081 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.jar" (runtime-name: "test.jar")
12:49:05,234 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0003: Processing weld deployment test.jar
12:49:05,257 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-5) HV000001: Hibernate Validator 5.3.5.Final
12:49:05,358 INFO  [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 3.0.2 (Final)
12:49:05,505 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Chakra' 8.2.8.Final
12:49:05,625 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."test.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.jar".WeldStartService: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1687)
	at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(Thread.java:785)
Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
	at org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.<clinit>(ObserverNotifier.java:480)
	at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
	at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
	at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
	at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
	at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1695)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1674)
	... 4 more
Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
	at java.lang.invoke.MethodHandles$Lookup.checkClassAccess(MethodHandles.java:371)
	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:281)
	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:264)
	at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:468)
	at java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:966)
	at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
	at java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:856)
	... 16 more

12:49:05,734 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 20) WFLYCLINF0002: Started client-mappings cache from ejb container
12:49:05,772 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "test.jar"}) - failure description: {
    "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
    Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
    Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]"]
}
12:49:05,774 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "test.jar" was rolled back with the following failure message: 
{
    "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
    Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
    Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]"]
}
12:49:05,791 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment test.jar (runtime-name: test.jar) in 17ms
{noformat}
EJB bean
{noformat}
12:37:04,047 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /home/mkopecky/git/wfly.05/standalone/data/content/fd/828118f8edbfcb42f98f3518dcc46baae85eaa/content
12:37:04,061 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.jar" (runtime-name: "test.jar")
12:37:04,238 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0003: Processing weld deployment test.jar
12:37:04,270 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.3.5.Final
12:37:04,319 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-2) WFLYEJB0473: JNDI bindings for session bean named 'LoggingBean' in deployment unit 'deployment "test.jar"' are as follows:

	java:global/test/LoggingBean!org.jboss.test.LoggingBean
	java:app/test/LoggingBean!org.jboss.test.LoggingBean
	java:module/LoggingBean!org.jboss.test.LoggingBean
	java:global/test/LoggingBean
	java:app/test/LoggingBean
	java:module/LoggingBean

12:37:04,387 INFO  [stdout] (MSC service thread 1-7) something
12:37:04,428 INFO  [org.jboss.weld.Version] (MSC service thread 1-7) WELD-000900: 3.0.2 (Final)
12:37:04,544 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Chakra' 8.2.8.Final
12:37:04,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."test.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.jar".WeldStartService: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1687)
	at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(Thread.java:785)
Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
	at org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.<clinit>(ObserverNotifier.java:480)
	at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
	at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
	at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
	at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
	at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1695)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1674)
	... 4 more
Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
	at java.lang.invoke.MethodHandles$Lookup.checkClassAccess(MethodHandles.java:371)
	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:281)
	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:264)
	at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:468)
	at java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:966)
	at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
	at java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:856)
	... 16 more

12:37:04,774 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) WFLYCLINF0002: Started client-mappings cache from ejb container
12:37:04,814 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "test.jar"}) - failure description: {
    "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
    Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
    Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
    "WFLYCTL0412: Required services that are not installed:" => [
        "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START",
        "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService",
        "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator",
        "jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"
    ],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator]",
        "jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]",
        "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService]",
        "jboss.deployment.unit.\"test.jar\".deploymentCompleteService is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]",
        "jboss.deployment.unit.\"test.jar\".moduleDeploymentRuntimeInformationStart is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]"
    ]
}
12:37:04,815 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "test.jar" was rolled back with the following failure message: 
{
    "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
    Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
    Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
    "WFLYCTL0412: Required services that are not installed:" => [
        "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START",
        "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService",
        "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator",
        "jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"
    ],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator]",
        "jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]",
        "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService]",
        "jboss.deployment.unit.\"test.jar\".deploymentCompleteService is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]",
        "jboss.deployment.unit.\"test.jar\".moduleDeploymentRuntimeInformationStart is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]"
    ]
}
12:37:04,830 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0028: Stopped deployment test.jar (runtime-name: test.jar) in 14ms
{noformat}
*Expected results:*
no errors





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 07:02:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 20 Dec 2017 07:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9625) Exception on Weld during
 inicialization of CDI/EJB bean on IBM JDK
In-Reply-To: <JIRA.12725702.1513771222000@Atlassian.JIRA>
References: <JIRA.12725702.1513771222000@Atlassian.JIRA>
	<JIRA.12725702.1513771222000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725702.1513771222000.9249.1513771320181@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFLY-9625:
--------------------------------
    Component/s: EJB


> Exception on Weld during inicialization of CDI/EJB bean on IBM JDK
> ------------------------------------------------------------------
>
>                 Key: WFLY-9625
>                 URL: https://issues.jboss.org/browse/WFLY-9625
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB
>            Reporter: Marek Kopeck?
>            Assignee: Martin Kouba
>            Priority: Blocker
>
> *Description of problem:*
> Exception on Weld during inicialization of CDI/EJB bean on IBM JDK
> Example of beans:
> {code:java}
> @RequestScoped
> public class LoggingBean {
>     static {
>         System.out.println("something");
>     }
> }
> {code}
> {code:java}
> @Singleton
> @Startup
> public class LoggingBean {
>     static {
>         System.out.println("something");
>     }
> }
> {code}
> *How reproducible:*
> Always on IBM JDK
> *Steps to Reproduce:*
> # Deploy deployment with beans from description
> *Actual results:*
> CDI bean:
> {noformat}
> 12:49:05,070 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /home/mkopecky/git/wfly.05/standalone/data/content/f8/f08bc0eb9dd3893743634459d1218cdbfeb4ac/content
> 12:49:05,081 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.jar" (runtime-name: "test.jar")
> 12:49:05,234 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0003: Processing weld deployment test.jar
> 12:49:05,257 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-5) HV000001: Hibernate Validator 5.3.5.Final
> 12:49:05,358 INFO  [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 3.0.2 (Final)
> 12:49:05,505 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Chakra' 8.2.8.Final
> 12:49:05,625 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."test.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.jar".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1687)
> 	at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.<clinit>(ObserverNotifier.java:480)
> 	at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
> 	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
> 	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> 	at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
> 	at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
> 	at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> 	at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1695)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1674)
> 	... 4 more
> Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at java.lang.invoke.MethodHandles$Lookup.checkClassAccess(MethodHandles.java:371)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:281)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:264)
> 	at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:468)
> 	at java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:966)
> 	at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
> 	at java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:856)
> 	... 16 more
> 12:49:05,734 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 20) WFLYCLINF0002: Started client-mappings cache from ejb container
> 12:49:05,772 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "test.jar"}) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]"]
> }
> 12:49:05,774 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "test.jar" was rolled back with the following failure message: 
> {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]"]
> }
> 12:49:05,791 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment test.jar (runtime-name: test.jar) in 17ms
> {noformat}
> EJB bean
> {noformat}
> 12:37:04,047 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /home/mkopecky/git/wfly.05/standalone/data/content/fd/828118f8edbfcb42f98f3518dcc46baae85eaa/content
> 12:37:04,061 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.jar" (runtime-name: "test.jar")
> 12:37:04,238 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0003: Processing weld deployment test.jar
> 12:37:04,270 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.3.5.Final
> 12:37:04,319 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-2) WFLYEJB0473: JNDI bindings for session bean named 'LoggingBean' in deployment unit 'deployment "test.jar"' are as follows:
> 	java:global/test/LoggingBean!org.jboss.test.LoggingBean
> 	java:app/test/LoggingBean!org.jboss.test.LoggingBean
> 	java:module/LoggingBean!org.jboss.test.LoggingBean
> 	java:global/test/LoggingBean
> 	java:app/test/LoggingBean
> 	java:module/LoggingBean
> 12:37:04,387 INFO  [stdout] (MSC service thread 1-7) something
> 12:37:04,428 INFO  [org.jboss.weld.Version] (MSC service thread 1-7) WELD-000900: 3.0.2 (Final)
> 12:37:04,544 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Chakra' 8.2.8.Final
> 12:37:04,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."test.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.jar".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1687)
> 	at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.<clinit>(ObserverNotifier.java:480)
> 	at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
> 	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
> 	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> 	at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
> 	at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
> 	at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> 	at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1695)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1674)
> 	... 4 more
> Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at java.lang.invoke.MethodHandles$Lookup.checkClassAccess(MethodHandles.java:371)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:281)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:264)
> 	at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:468)
> 	at java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:966)
> 	at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
> 	at java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:856)
> 	... 16 more
> 12:37:04,774 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) WFLYCLINF0002: Started client-mappings cache from ejb container
> 12:37:04,814 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "test.jar"}) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator",
>         "jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"
>     ],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator]",
>         "jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService]",
>         "jboss.deployment.unit.\"test.jar\".deploymentCompleteService is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]",
>         "jboss.deployment.unit.\"test.jar\".moduleDeploymentRuntimeInformationStart is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]"
>     ]
> }
> 12:37:04,815 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "test.jar" was rolled back with the following failure message: 
> {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator",
>         "jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"
>     ],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator]",
>         "jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService]",
>         "jboss.deployment.unit.\"test.jar\".deploymentCompleteService is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]",
>         "jboss.deployment.unit.\"test.jar\".moduleDeploymentRuntimeInformationStart is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]"
>     ]
> }
> 12:37:04,830 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0028: Stopped deployment test.jar (runtime-name: test.jar) in 14ms
> {noformat}
> *Expected results:*
> no errors



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 07:10:01 2017
From: issues at jboss.org (kobogian hitis (JIRA))
Date: Wed, 20 Dec 2017 07:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6696) Problem with infinispan,
 Unable to acquire lock after 15 seconds for key
In-Reply-To: <JIRA.12630465.1465500016000@Atlassian.JIRA>
References: <JIRA.12630465.1465500016000@Atlassian.JIRA>
	<JIRA.12630465.1465500016000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12630465.1465500016000.9283.1513771801015@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507422#comment-13507422 ] 

kobogian hitis commented on WFLY-6696:
--------------------------------------

Can you please advice on any workaround for this issue? 
We get it on 10.1.0.final (2-node standalone-full-ha.xml).

Is there any configuration change so that we do not get this as often.  
Can these 15 seconds be increased from somewhere?

> Problem with infinispan, Unable to acquire lock after 15 seconds for key 
> -------------------------------------------------------------------------
>
>                 Key: WFLY-6696
>                 URL: https://issues.jboss.org/browse/WFLY-6696
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 10.0.0.Final
>         Environment: linux debian, apache, oracle database 
>            Reporter: Bruno Silva
>            Assignee: Paul Ferraro
>         Attachments: error.txt
>
>
> I have two nodes in cluster using standalone-ha.xml, but when put <distributable/> into web.xml the error below has happened frenquently and I'm using SSO.
> {noformat}
> 2016-06-09 14:46:55,160 ERROR [io.undertow.request] (default task-93) UT005071: Undertow request failed HttpServerExchange{ GET /intranet/app/pagina.action request Cookie=[JSESSIONID=hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK.node3; JSESSIONIDSSO=iYEO1MGfzBBsKmvmuO8HPz0whseKXJmRzjuuuiRQ; org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK and requestor GlobalTransaction:<node3>:475504:local. Lock is held by GlobalTransaction:<node3>:474447:local
> 	at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAllAndRecord(AbstractLockingInterceptor.java:199)
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:199)
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:165)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:184)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> 	at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> 	at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:78)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> 	at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:828)
> 	at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:810)
> 	at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:84)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:69)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> 	at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:139)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:726)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:756)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:760)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:168)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:319)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 07:34:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 07:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9626) Defining security-domain in
 jboss-app.xml where EJB deployment does not have security settings results
 in IllegalStateException
In-Reply-To: <JIRA.12725707.1513773228000@Atlassian.JIRA>
References: <JIRA.12725707.1513773228000@Atlassian.JIRA>
	<JIRA.12725707.1513773228216@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725707.1513773228000.9443.1513773240373@Atlassian.JIRA>

Darran Lofthouse created WFLY-9626:
--------------------------------------

             Summary: Defining security-domain in jboss-app.xml where EJB deployment does not have security settings results in IllegalStateException
                 Key: WFLY-9626
                 URL: https://issues.jboss.org/browse/WFLY-9626
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse


{noformat}
Caused by: java.lang.IllegalStateException: PBOX00075: The property AuthorizationManager is null
????????at org.jboss.security.plugins.javaee.EJBAuthorizationHelper.authorize(EJBAuthorizationHelper.java:298)
????????at org.jboss.as.security.service.SimpleSecurityManager.authorize(SimpleSecurityManager.java:267)
????????... 121 more
{noformat}




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 07:35:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 07:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9626) Defining security-domain in
 jboss-app.xml where EJB deployment does not have security settings results
 in IllegalStateException
In-Reply-To: <JIRA.12725707.1513773228000@Atlassian.JIRA>
References: <JIRA.12725707.1513773228000@Atlassian.JIRA>
	<JIRA.12725707.1513773228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725707.1513773228000.9454.1513773300350@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-9626:
-----------------------------------
    Affects Version/s: 10.1.0.Final


> Defining security-domain in jboss-app.xml where EJB deployment does not have security settings results in IllegalStateException
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9626
>                 URL: https://issues.jboss.org/browse/WFLY-9626
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 10.1.0.Final
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>
> {noformat}
> Caused by: java.lang.IllegalStateException: PBOX00075: The property AuthorizationManager is null
> ????????at org.jboss.security.plugins.javaee.EJBAuthorizationHelper.authorize(EJBAuthorizationHelper.java:298)
> ????????at org.jboss.as.security.service.SimpleSecurityManager.authorize(SimpleSecurityManager.java:267)
> ????????... 121 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 07:52:00 2017
From: issues at jboss.org (=?UTF-8?Q?Guido_J=C3=A4kel_=28JIRA=29?=)
Date: Wed, 20 Dec 2017 07:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9626) Defining security-domain in
 jboss-app.xml where EJB deployment does not have security settings results
 in IllegalStateException
In-Reply-To: <JIRA.12725707.1513773228000@Atlassian.JIRA>
References: <JIRA.12725707.1513773228000@Atlassian.JIRA>
	<JIRA.12725707.1513773228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725707.1513773228000.9516.1513774320524@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507445#comment-13507445 ] 

Guido J?kel commented on WFLY-9626:
-----------------------------------

For reference, here some declaration of the deployment where the problem was discovered

{code:title=jboss-app.xml}
<!-- generated 20171206-095642 by _genoverlayfiles for "api.nbn-resolving.org/ROOT.ear" -->

<jboss-app xmlns="http://java.sun.com/xml/ns/javaee"              <<---- this NS is need to have access to the resource-ref tag
           xmlns:jboss="http://www.jboss.com/xml/ns/javaee"          <<---- this NS is need to have access to the security-domain tag
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-app_7_0.xsd"
                 version="7.0">

  <module>
    <web>
      <web-uri>
        urnadministration-api-impl-1.0.3-SNAPSHOT.war
      </web-uri>
      <context-root>
        /
      </context-root>
    </web>
  </module>

  <resource-ref>
    <res-ref-name>java:/jdbc/urn</res-ref-name>
    <jndi-name>java:jboss/datasources/epicur</jndi-name>
  </resource-ref>

  <!--  jboss:security-domain>     <<---- if enabled here, the applications throws the exception
    api.nbn-resolving.org/ROOT
  </jboss:security-domain  -->

</jboss-app>
{code}

{code:title=urnadministration-api-impl-*.war/WEB-INF/jboss-web.xml}
<?xml version="1.0" encoding="UTF-8"?>  
<!-- generated 20171206-095642 by _genoverlayfiles for "api.nbn-resolving.org/ROOT.ear" -->

<jboss-web
  xmlns="http://www.jboss.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd"
>  

  <virtual-host>
    api.nbn-resolving.org
  </virtual-host>

  <security-domain>        <<--- if disabled here, the app can't authorize
    api.nbn-resolving.org/ROOT
  </security-domain>

</jboss-web>   
{code}

> Defining security-domain in jboss-app.xml where EJB deployment does not have security settings results in IllegalStateException
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9626
>                 URL: https://issues.jboss.org/browse/WFLY-9626
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 10.1.0.Final
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>
> {noformat}
> Caused by: java.lang.IllegalStateException: PBOX00075: The property AuthorizationManager is null
> ????????at org.jboss.security.plugins.javaee.EJBAuthorizationHelper.authorize(EJBAuthorizationHelper.java:298)
> ????????at org.jboss.as.security.service.SimpleSecurityManager.authorize(SimpleSecurityManager.java:267)
> ????????... 121 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 08:14:00 2017
From: issues at jboss.org (kobogian hitis (JIRA))
Date: Wed, 20 Dec 2017 08:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4616) Problem with distributable
 sessions on long IO
In-Reply-To: <JIRA.12571158.1431164229000@Atlassian.JIRA>
References: <JIRA.12571158.1431164229000@Atlassian.JIRA>
	<JIRA.12571158.1431164229000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571158.1431164229000.9581.1513775640358@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507447#comment-13507447 ] 

kobogian hitis commented on WFLY-4616:
--------------------------------------

Can you please provide the way to disable batching on wildfly 10.1.0?

> Problem with distributable sessions on long IO
> ----------------------------------------------
>
>                 Key: WFLY-4616
>                 URL: https://issues.jboss.org/browse/WFLY-4616
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.1.0.Final, 8.2.0.Final, 10.0.0.Final
>            Reporter: Pawe? Go?dzikowski
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> Hi,
> I faced problem with wildfly <distributable/> what I want to ask is if it will be fixed/or is fixed in new versions on wildfly.
> The problem is when server starts performing long operation, ex. moving file to ntfs file system wildfly hangs over and starts to throw exceptions.. I tested it on wildfly 8.1 and 8.2 and wildfly  and problem still occures.
> Disscusion about it you can find:
> https://developer.jboss.org/message/908454?et=watches.email.thread#908454
> Exception:
> 13:19:00,670 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-19) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [j4-c64fI_msgIgF60Eqw_q72] for requestor [GlobalTransaction:<pgozdzik/web>:6832:local]! Lock held by [GlobalTransaction:<pgozdzik/web>:6830:local]
>     at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198)
>     at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171)
>     at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:169)
>     at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitGetKeyValueCommand(PessimisticLockingInterceptor.java:70)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:226)
>     at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:263)
>     at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:247)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
>     at org.infinispan.CacheImpl.get(CacheImpl.java:377)
>     at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)
>     at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
>     at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
>     at org.jboss.as.clustering.infinispan.invoker.Locator$LockingFindOperation.invoke(Locator.java:71)
>     at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
>     at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
>     at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:109)
>     at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:55)
>     at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:149)
>     at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
>     at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:353) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:168) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:153) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
>    
> 13:19:00,727 ERROR [io.undertow.request] (default task-19) UT005023: Exception handling request to /test: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=6832}, status=1} is not in a valid state to be invoking cache operations on.
>     at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)
>     at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)
>     at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)
>     at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:263)
>     at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:247)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
>     at org.infinispan.CacheImpl.get(CacheImpl.java:377)
>     at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)
>     at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
>     at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
>     at org.jboss.as.clustering.infinispan.invoker.Locator$LockingFindOperation.invoke(Locator.java:71)
>     at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
>     at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
>     at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:109)
>     at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:55)
>     at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:149)
>     at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
>     at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:353) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:168) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:153) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> - See more at: https://developer.jboss.org/message/908454?et=watches.email.thread#908454



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 08:40:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 20 Dec 2017 08:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3469) Add legacy test controllers
 for EAP 7.1.0
In-Reply-To: <JIRA.12725715.1513777158000@Atlassian.JIRA>
References: <JIRA.12725715.1513777158000@Atlassian.JIRA>
	<JIRA.12725715.1513777158080@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725715.1513777158000.9650.1513777200438@Atlassian.JIRA>

Kabir Khan created WFCORE-3469:
----------------------------------

             Summary: Add legacy test controllers for EAP 7.1.0
                 Key: WFCORE-3469
                 URL: https://issues.jboss.org/browse/WFCORE-3469
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Tomaz Cerar






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 08:49:00 2017
From: issues at jboss.org (Katerina Novotna (JIRA))
Date: Wed, 20 Dec 2017 08:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3221) Support for | and >>
	operators
In-Reply-To: <JIRA.12709757.1504265911000@Atlassian.JIRA>
References: <JIRA.12709757.1504265911000@Atlassian.JIRA>
	<JIRA.12709757.1504265911000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709757.1504265911000.9665.1513777740116@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507458#comment-13507458 ] 

Katerina Novotna commented on WFCORE-3221:
------------------------------------------

It would be nice if grep command would support '-v' (inverted match) option as well.

> Support for | and >> operators
> ------------------------------
>
>                 Key: WFCORE-3221
>                 URL: https://issues.jboss.org/browse/WFCORE-3221
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> Aesh 1.0 comes with a set of useful operators. 2 are of particular interest in CLI:
> In order to extend the CLI ?>? support with the ability to append to a file, ?>>? support is required.
> To make interesting combination of commands (eg: grep, cat, less), the ?|? operator is required.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 09:06:00 2017
From: issues at jboss.org (Andrej Podhradsky (JIRA))
Date: Wed, 20 Dec 2017 09:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2122) Error when drl file is
 opened with in project with runtime classes
In-Reply-To: <JIRA.12720188.1510218403000@Atlassian.JIRA>
References: <JIRA.12720188.1510218403000@Atlassian.JIRA>
	<JIRA.12720188.1510218403000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720188.1510218403000.9693.1513778760589@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrej Podhradsky closed DROOLS-2122.
-------------------------------------


Verified with Devstudio IS 11.1.0.CR2 which contains Drools 7.5.0.Final

> Error when drl file is opened with in project with runtime classes 
> -------------------------------------------------------------------
>
>                 Key: DROOLS-2122
>                 URL: https://issues.jboss.org/browse/DROOLS-2122
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>    Affects Versions: 7.3.0.Final
>         Environment: DevstudioIS 11.1.0.Beta1
> Brms 6.4.6.GA
>            Reporter: Tomas David
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 7.5.0.Final
>
>         Attachments: Screenshot from 2017-11-09 09-55-05.png, devstudiolog.log
>
>
> If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> This blocks also other functions like add a breakpoint or show content assist menu.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 09:06:00 2017
From: issues at jboss.org (Katerina Novotna (JIRA))
Date: Wed, 20 Dec 2017 09:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3221) Support for | and >>
	operators
In-Reply-To: <JIRA.12709757.1504265911000@Atlassian.JIRA>
References: <JIRA.12709757.1504265911000@Atlassian.JIRA>
	<JIRA.12709757.1504265911000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709757.1504265911000.9701.1513778760778@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507462#comment-13507462 ] 

Katerina Novotna commented on WFCORE-3221:
------------------------------------------

Here is the list of most common options of grep which could be nice to have as well:
* Show line number while displaying the output using grep -n
* Show only the matched string -o
* Counting the number of matches using grep -c
* Display the lines which does not matches all the given pattern. -e
** grep -e "pattern" -e "pattern"
* Invert match using grep -v
* Displaying lines before/after/around the match using grep -A, -B and -C
* Checking for full words, not for sub-strings using grep -w

> Support for | and >> operators
> ------------------------------
>
>                 Key: WFCORE-3221
>                 URL: https://issues.jboss.org/browse/WFCORE-3221
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> Aesh 1.0 comes with a set of useful operators. 2 are of particular interest in CLI:
> In order to extend the CLI ?>? support with the ability to append to a file, ?>>? support is required.
> To make interesting combination of commands (eg: grep, cat, less), the ?|? operator is required.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 09:30:00 2017
From: issues at jboss.org (=?UTF-8?Q?Donatas_=C4=8Ciuk=C5=A1ys_=28JIRA=29?=)
Date: Wed, 20 Dec 2017 09:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-6441) Transaction automatically
 started for MDB even though it uses BMT
In-Reply-To: <JIRA.12484019.1359739107000@Atlassian.JIRA>
References: <JIRA.12484019.1359739107000@Atlassian.JIRA>
	<JIRA.12484019.1359739107000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484019.1359739107000.10008.1513780200330@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/AS7-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507480#comment-13507480 ] 

Donatas ?iuk?ys commented on AS7-6441:
--------------------------------------

This issue is not fixed. We reproduced it on EAP 7.0.5. Please re-open.

> Transaction automatically started for MDB even though it uses BMT
> -----------------------------------------------------------------
>
>                 Key: AS7-6441
>                 URL: https://issues.jboss.org/browse/AS7-6441
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.1.3.Final (EAP)
>            Reporter: Justin Bertram
>            Assignee: jaikiran pai
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> When an MDB uses BMT a transaction is still begun when onMessage() is invoked.  This is because org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent#isDeliveryTransacted doesn't check whether or not the MDB is using BMT.
> You can workaround this issue by using CMT with NOT_SUPPORTED.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 09:57:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 20 Dec 2017 09:57: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.10159.1513781820293@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507497#comment-13507497 ] 

Jan Kalina commented on ELY-283:
--------------------------------

OK, I has found the problem: the SIGSEGV in cfree occures when variable *minor* passed into the *gss_accept_sec_context* is not initialized to zero!
After following modification acceptContext call finish successfully:
{code}
-  OM_uint32 minor, major;
+  OM_uint32 minor = 0, major;
{code}
As the *minor_status* parameter is defined as output, I suppose this is bug of kerberos library and zero initialization of minor should not be required.

> 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: openjdk-patch-native-mechs.patch
>
>
> 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 Dec 20 09:58:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 20 Dec 2017 09:58: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.10164.1513781880140@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507497#comment-13507497 ] 

Jan Kalina edited comment on ELY-283 at 12/20/17 9:57 AM:
----------------------------------------------------------

OK, I has found the problem: the SIGSEGV in cfree occures when variable *minor* passed into the *gss_accept_sec_context* is not initialized to zero!
After following modification acceptContext call finish successfully:
{code}
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
-  OM_uint32 minor, major;
+  OM_uint32 minor = 0, major;
{code}
As the *minor_status* parameter is defined as output, I suppose this is bug of kerberos library and zero initialization of minor should not be required.


was (Author: honza889):
OK, I has found the problem: the SIGSEGV in cfree occures when variable *minor* passed into the *gss_accept_sec_context* is not initialized to zero!
After following modification acceptContext call finish successfully:
{code}
-  OM_uint32 minor, major;
+  OM_uint32 minor = 0, major;
{code}
As the *minor_status* parameter is defined as output, I suppose this is bug of kerberos library and zero initialization of minor should not be required.

> 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: openjdk-patch-native-mechs.patch
>
>
> 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 Dec 20 10:02:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 20 Dec 2017 10:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-124) Java 8+ supports unbound SASL
 servers; GSSAPI and DIGEST-MD5 both use this value
In-Reply-To: <JIRA.12557393.1415939070000@Atlassian.JIRA>
References: <JIRA.12557393.1415939070000@Atlassian.JIRA>
	<JIRA.12557393.1415939070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557393.1415939070000.10178.1513782120366@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-124:
---------------------------
    Affects Version/s: 1.2.0.Beta10


> Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value
> --------------------------------------------------------------------------------
>
>                 Key: ELY-124
>                 URL: https://issues.jboss.org/browse/ELY-124
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: SASL
>    Affects Versions: 1.2.0.Beta10
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null.  If null, the server name is considered "unbound" and the client can select what server name it wants to use.
> The release notes say:
> {quote}
> SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803.
> {quote}
> The updated JavaDoc says:
> {quote}
> serverName - The fully qualified host name of the server to authenticate to, or null if the server is not bound to any specific host name. If the mechanism does not allow an unbound server, a SaslException will be thrown.
> {quote}
> The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803
> The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 10:03:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 20 Dec 2017 10:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4616) Problem with distributable
 sessions on long IO
In-Reply-To: <JIRA.12571158.1431164229000@Atlassian.JIRA>
References: <JIRA.12571158.1431164229000@Atlassian.JIRA>
	<JIRA.12571158.1431164229000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571158.1431164229000.10185.1513782180363@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507499#comment-13507499 ] 

Paul Ferraro commented on WFLY-4616:
------------------------------------

>From the configuration XML, you can either:
* Replace <transaction mode="BATCH"/> with <transaction mode="NONE"/>
* Remove <transaction mode="BATCH"/> altogether - this will use the default mode of NONE. 

>From the CLI, any of the following will work:
* /subsystem=infinispan/cache-container=web/distributed-cache=dist/component=transaction:write-attribute(name=mode, value=NONE){allow-resource-service-restart=true}
* /subsystem=infinispan/cache-container=web/distributed-cache=dist/component=transaction:undefine-attribute(name=mode){allow-resource-service-restart=true}   This will revert the mode attribute to its default value of NONE.
* /subsystem=infinispan/cache-container=web/distributed-cache=dist/component=transaction:remove(){allow-resource-service-restart=true}   As a required cache component, the resource will be recreated using its default values.

When using a non-transactional cache (where each cache operation is a separate tx), REPEATABLE_READ doesn't make much sense, so I would suggest switching the lock isolation mode to READ_COMMITTED.

> Problem with distributable sessions on long IO
> ----------------------------------------------
>
>                 Key: WFLY-4616
>                 URL: https://issues.jboss.org/browse/WFLY-4616
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.1.0.Final, 8.2.0.Final, 10.0.0.Final
>            Reporter: Pawe? Go?dzikowski
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> Hi,
> I faced problem with wildfly <distributable/> what I want to ask is if it will be fixed/or is fixed in new versions on wildfly.
> The problem is when server starts performing long operation, ex. moving file to ntfs file system wildfly hangs over and starts to throw exceptions.. I tested it on wildfly 8.1 and 8.2 and wildfly  and problem still occures.
> Disscusion about it you can find:
> https://developer.jboss.org/message/908454?et=watches.email.thread#908454
> Exception:
> 13:19:00,670 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-19) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [j4-c64fI_msgIgF60Eqw_q72] for requestor [GlobalTransaction:<pgozdzik/web>:6832:local]! Lock held by [GlobalTransaction:<pgozdzik/web>:6830:local]
>     at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198)
>     at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171)
>     at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:169)
>     at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitGetKeyValueCommand(PessimisticLockingInterceptor.java:70)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:226)
>     at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:263)
>     at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:247)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
>     at org.infinispan.CacheImpl.get(CacheImpl.java:377)
>     at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)
>     at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
>     at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
>     at org.jboss.as.clustering.infinispan.invoker.Locator$LockingFindOperation.invoke(Locator.java:71)
>     at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
>     at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
>     at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:109)
>     at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:55)
>     at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:149)
>     at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
>     at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:353) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:168) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:153) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
>    
> 13:19:00,727 ERROR [io.undertow.request] (default task-19) UT005023: Exception handling request to /test: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=6832}, status=1} is not in a valid state to be invoking cache operations on.
>     at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)
>     at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)
>     at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)
>     at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:263)
>     at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:247)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
>     at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>     at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
>     at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
>     at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
>     at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
>     at org.infinispan.CacheImpl.get(CacheImpl.java:377)
>     at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)
>     at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
>     at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
>     at org.jboss.as.clustering.infinispan.invoker.Locator$LockingFindOperation.invoke(Locator.java:71)
>     at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
>     at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
>     at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:109)
>     at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:55)
>     at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:149)
>     at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
>     at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:353) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:168) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:153) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
>     at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> - See more at: https://developer.jboss.org/message/908454?et=watches.email.thread#908454



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Dec 20 10:06:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 20 Dec 2017 10:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6696) Problem with infinispan,
 Unable to acquire lock after 15 seconds for key
In-Reply-To: <JIRA.12630465.1465500016000@Atlassian.JIRA>
References: <JIRA.12630465.1465500016000@Atlassian.JIRA>
	<JIRA.12630465.1465500016000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12630465.1465500016000.10208.1513782360705@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507502#comment-13507502 ] 

Paul Ferraro commented on WFLY-6696:
------------------------------------

To support concurrent distributed web session access, you should configure your web session cache configuration to be non-transactional, with READ_COMMITTED isolation.
We're working on improving distributed web session concurrency over the next few releases, such that sessions are fully concurrent, but only on one node at a time.

> Problem with infinispan, Unable to acquire lock after 15 seconds for key 
> -------------------------------------------------------------------------
>
>                 Key: WFLY-6696
>                 URL: https://issues.jboss.org/browse/WFLY-6696
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 10.0.0.Final
>         Environment: linux debian, apache, oracle database 
>            Reporter: Bruno Silva
>            Assignee: Paul Ferraro
>         Attachments: error.txt
>
>
> I have two nodes in cluster using standalone-ha.xml, but when put <distributable/> into web.xml the error below has happened frenquently and I'm using SSO.
> {noformat}
> 2016-06-09 14:46:55,160 ERROR [io.undertow.request] (default task-93) UT005071: Undertow request failed HttpServerExchange{ GET /intranet/app/pagina.action request Cookie=[JSESSIONID=hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK.node3; JSESSIONIDSSO=iYEO1MGfzBBsKmvmuO8HPz0whseKXJmRzjuuuiRQ; org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK and requestor GlobalTransaction:<node3>:475504:local. Lock is held by GlobalTransaction:<node3>:474447:local
> 	at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
> 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAllAndRecord(AbstractLockingInterceptor.java:199)
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:199)
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:165)
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:184)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> 	at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> 	at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:78)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> 	at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 	at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:828)
> 	at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:810)
> 	at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:84)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:69)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> 	at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:139)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:726)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:756)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:760)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:168)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:319)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 10:14:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 20 Dec 2017 10:14: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.10267.1513782840691@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507511#comment-13507511 ] 

David Lloyd commented on ELY-283:
---------------------------------

I think you are correct that it must be a bug in the library, so an upstream bug should be reported.  I think that the OpenJDK security team would accept the patch to initialize it to 0 though, knowing that it works around such a bug.

Nice job!

> 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: openjdk-patch-native-mechs.patch
>
>
> 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 Dec 20 10:33:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 20 Dec 2017 10:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-124) Java 8+ supports unbound SASL
 servers; GSSAPI and DIGEST-MD5 both use this value
In-Reply-To: <JIRA.12557393.1415939070000@Atlassian.JIRA>
References: <JIRA.12557393.1415939070000@Atlassian.JIRA>
	<JIRA.12557393.1415939070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557393.1415939070000.10352.1513783980231@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507522#comment-13507522 ] 

Jan Kalina commented on ELY-124:
--------------------------------

[~mchoma] The client provides the serverName when server is created as unbound (serverName = null).
Negotiated property mean value is provided by opposite side of the communication - so yes, client in case of SaslServer.

Ad task 8001104: this is feature request for feature, which is necessary to implement unbound for GS2/GSSAPI sasl server - this is used in attached pull request.

> Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value
> --------------------------------------------------------------------------------
>
>                 Key: ELY-124
>                 URL: https://issues.jboss.org/browse/ELY-124
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: SASL
>    Affects Versions: 1.2.0.Beta10
>            Reporter: David Lloyd
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null.  If null, the server name is considered "unbound" and the client can select what server name it wants to use.
> The release notes say:
> {quote}
> SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803.
> {quote}
> The updated JavaDoc says:
> {quote}
> serverName - The fully qualified host name of the server to authenticate to, or null if the server is not bound to any specific host name. If the mechanism does not allow an unbound server, a SaslException will be thrown.
> {quote}
> The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803
> The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:05:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1470) Release WildFly Elytron
	1.2.0.Beta11
In-Reply-To: <JIRA.12725764.1513785845000@Atlassian.JIRA>
References: <JIRA.12725764.1513785845000@Atlassian.JIRA>
	<JIRA.12725764.1513785845085@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725764.1513785845000.10438.1513785900268@Atlassian.JIRA>

Darran Lofthouse created ELY-1470:
-------------------------------------

             Summary: Release WildFly Elytron 1.2.0.Beta11
                 Key: ELY-1470
                 URL: https://issues.jboss.org/browse/ELY-1470
             Project: WildFly Elytron
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.2.0.Beta11






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:06:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 20 Dec 2017 11:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1461) Java 9: Eliminate reflection
 warning from security manager
In-Reply-To: <JIRA.12724492.1513096339000@Atlassian.JIRA>
References: <JIRA.12724492.1513096339000@Atlassian.JIRA>
	<JIRA.12724492.1513096339000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724492.1513096339000.10444.1513785960282@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved ELY-1461.
------------------------------
    Fix Version/s: 1.2.0.Beta11
       Resolution: Done


> Java 9: Eliminate reflection warning from security manager
> ----------------------------------------------------------
>
>                 Key: ELY-1461
>                 URL: https://issues.jboss.org/browse/ELY-1461
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Security Manager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.2.0.Beta11
>
>
> Java 9 does not take kindly to our invasive reflection into AccessControlContext; also, if the implementation happens to not have the same fields, we fail to start the entire application server.
> Our enhanced debug output is nice but for now this should be changed to be Java 9-safe.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:08:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 20 Dec 2017 11:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3470) Add an option to configure
 the service display name during service install
In-Reply-To: <JIRA.12725476.1513598972000@Atlassian.JIRA>
References: <JIRA.12725476.1513598972000@Atlassian.JIRA>
	<JIRA.12725476.1513598972000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725476.1513598972000.10469.1513786080431@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-9619 to WFCORE-3470:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-3470  (was: WFLY-9619)
    Component/s: Scripts
                     (was: Scripts)


> Add an option to configure the service display name during service install
> --------------------------------------------------------------------------
>
>                 Key: WFCORE-3470
>                 URL: https://issues.jboss.org/browse/WFCORE-3470
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Scripts
>            Reporter: David Le Borgne
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> The docs/contrib/scripts/service.bat lacks an option to configure the service display name during service installation. The service display name will take the value of the service name.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:08:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3471) Upgrade WildFly Elytron to
	1.2.0.Beta11
In-Reply-To: <JIRA.12725766.1513786063000@Atlassian.JIRA>
References: <JIRA.12725766.1513786063000@Atlassian.JIRA>
	<JIRA.12725766.1513786063331@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725766.1513786063000.10476.1513786080606@Atlassian.JIRA>

Darran Lofthouse created WFCORE-3471:
----------------------------------------

             Summary: Upgrade WildFly Elytron to 1.2.0.Beta11
                 Key: WFCORE-3471
                 URL: https://issues.jboss.org/browse/WFCORE-3471
             Project: WildFly Core
          Issue Type: Component Upgrade
          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  Wed Dec 20 11:13:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 20 Dec 2017 11:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3470) Add an option to configure
 the service display name during service install
In-Reply-To: <JIRA.12725476.1513598972000@Atlassian.JIRA>
References: <JIRA.12725476.1513598972000@Atlassian.JIRA>
	<JIRA.12725476.1513598972000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725476.1513598972000.10507.1513786380204@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-3470:
----------------------------------------

    Fix Version/s: 4.0.0.Alpha6
         Assignee: David Le Borgne  (was: Tomaz Cerar)
       Resolution: Done


> Add an option to configure the service display name during service install
> --------------------------------------------------------------------------
>
>                 Key: WFCORE-3470
>                 URL: https://issues.jboss.org/browse/WFCORE-3470
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Scripts
>            Reporter: David Le Borgne
>            Assignee: David Le Borgne
>            Priority: Minor
>             Fix For: 4.0.0.Alpha6
>
>
> The docs/contrib/scripts/service.bat lacks an option to configure the service display name during service installation. The service display name will take the value of the service name.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:38:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 20 Dec 2017 11:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3472) Add
 HostExcludeResourceDefinition.KnownRelease items for EAP 7.1
In-Reply-To: <JIRA.12725772.1513787848000@Atlassian.JIRA>
References: <JIRA.12725772.1513787848000@Atlassian.JIRA>
	<JIRA.12725772.1513787848664@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725772.1513787848000.10702.1513787880199@Atlassian.JIRA>

Kabir Khan created WFCORE-3472:
----------------------------------

             Summary: Add HostExcludeResourceDefinition.KnownRelease items for EAP 7.1
                 Key: WFCORE-3472
                 URL: https://issues.jboss.org/browse/WFCORE-3472
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Kabir Khan






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:44:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1470) Release WildFly Elytron
	1.2.0.Beta11
In-Reply-To: <JIRA.12725764.1513785845000@Atlassian.JIRA>
References: <JIRA.12725764.1513785845000@Atlassian.JIRA>
	<JIRA.12725764.1513785845000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725764.1513785845000.10731.1513788240912@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-1470.
-----------------------------------
    Resolution: Done


> Release WildFly Elytron 1.2.0.Beta11
> ------------------------------------
>
>                 Key: ELY-1470
>                 URL: https://issues.jboss.org/browse/ELY-1470
>             Project: WildFly Elytron
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta11
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:45:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45:01 -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.10746.1513788301607@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.Beta12
                       (was: 1.2.0.Beta11)


> 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.Beta12
>
>
> https://tools.ietf.org/html/rfc8053



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:45:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45:01 -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.10752.1513788301779@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.Beta12
                       (was: 1.2.0.Beta11)


> 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.Beta12
>
>
> 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  Wed Dec 20 11:45:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45:01 -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.10755.1513788301845@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.Beta12
                       (was: 1.2.0.Beta11)


> 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.Beta12
>
>
> 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  Wed Dec 20 11:45:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1463) Programatic authentication is
 not creating a HTTP session if one does not already exist.
In-Reply-To: <JIRA.12724646.1513168826000@Atlassian.JIRA>
References: <JIRA.12724646.1513168826000@Atlassian.JIRA>
	<JIRA.12724646.1513168826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724646.1513168826000.10758.1513788301901@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1463:
----------------------------------
    Fix Version/s: 1.2.0.Beta12
                       (was: 1.2.0.Beta11)


> Programatic authentication is not creating a HTTP session if one does not already exist.
> ----------------------------------------------------------------------------------------
>
>                 Key: ELY-1463
>                 URL: https://issues.jboss.org/browse/ELY-1463
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>            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 Dec 20 11:45:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1462) Move programatic
 authentication from Elytron Web to Elytron
In-Reply-To: <JIRA.12724645.1513168784000@Atlassian.JIRA>
References: <JIRA.12724645.1513168784000@Atlassian.JIRA>
	<JIRA.12724645.1513168784000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724645.1513168784000.10761.1513788301962@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1462:
----------------------------------
    Fix Version/s: 1.2.0.Beta12
                       (was: 1.2.0.Beta11)


> Move programatic authentication from Elytron Web to Elytron
> -----------------------------------------------------------
>
>                 Key: ELY-1462
>                 URL: https://issues.jboss.org/browse/ELY-1462
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> The core implementation should be following the same pattern as is followed for mechanisms such as FORM authentication, this should not need to live within the HTTP server integration project.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:45:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45: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.10766.1513788302102@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.Beta12
                       (was: 1.2.0.Beta11)


>  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.Beta12
>
>         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  Wed Dec 20 11:45:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45: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.10770.1513788302176@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.Beta12
                       (was: 1.2.0.Beta11)


> 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.Beta12
>
>
> 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  Wed Dec 20 11:45:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45: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.10773.1513788302237@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.Beta12
                       (was: 1.2.0.Beta11)


> 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.Beta12
>
>
> 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  Wed Dec 20 11:45:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45: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.10777.1513788302328@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.Beta12
                       (was: 1.2.0.Beta11)


> 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: Darran Lofthouse
>             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  Wed Dec 20 11:45:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45: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.10780.1513788302430@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.Beta12
                       (was: 1.2.0.Beta11)


> 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.Beta12
>
>
> 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  Wed Dec 20 11:45:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45: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.10783.1513788302531@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.Beta12
                       (was: 1.2.0.Beta11)


> 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.Beta12
>
>
> 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  Wed Dec 20 11:45:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45:02 -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.10789.1513788302643@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.Beta12
                       (was: 1.2.0.Beta11)


> 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.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:45:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1386) <certificate-revocation-list
 /> should also support a URI and resource in addition to path.
In-Reply-To: <JIRA.12714964.1507288406000@Atlassian.JIRA>
References: <JIRA.12714964.1507288406000@Atlassian.JIRA>
	<JIRA.12714964.1507288406000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12714964.1507288406000.10793.1513788302754@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1386:
----------------------------------
    Fix Version/s: 1.2.0.Beta12
                       (was: 1.2.0.Beta11)


> <certificate-revocation-list /> should also support a URI and resource in addition to path.
> -------------------------------------------------------------------------------------------
>
>                 Key: ELY-1386
>                 URL: https://issues.jboss.org/browse/ELY-1386
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Assignee: Martin Mazanek
>             Fix For: 1.2.0.Beta12
>
>
> KeyStores can be loaded from a path, a URI, or as a resource - the certificate revocation list should be the same.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 11:45:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 11:45:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1370) CachingSecurityRealm and
 RealmIdentityCache missing TRACE logging
In-Reply-To: <JIRA.12712605.1505920818000@Atlassian.JIRA>
References: <JIRA.12712605.1505920818000@Atlassian.JIRA>
	<JIRA.12712605.1505920818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712605.1505920818000.10797.1513788302830@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1370:
----------------------------------
    Fix Version/s: 1.2.0.Beta12
                       (was: 1.2.0.Beta11)


> CachingSecurityRealm and RealmIdentityCache missing TRACE logging
> -----------------------------------------------------------------
>
>                 Key: ELY-1370
>                 URL: https://issues.jboss.org/browse/ELY-1370
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Realms
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> Where caching is in use there is no TRACE logging showing the activity in the cache.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 12:04:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Dec 2017 12:04: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.10865.1513789440557@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 Classes in the Elytron Subsystem  (was: Minimise Classes in the Elytron Subsystem)


> 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 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.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 12:47:00 2017
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Wed, 20 Dec 2017 12:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9627) Update Http Core to 4.4.5 and
 Client to 4.5.2
In-Reply-To: <JIRA.12725779.1513791964000@Atlassian.JIRA>
References: <JIRA.12725779.1513791964000@Atlassian.JIRA>
	<JIRA.12725779.1513791964987@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725779.1513791964000.10916.1513792020142@Atlassian.JIRA>

Romain Pelisse created WFLY-9627:
------------------------------------

             Summary: Update Http Core to 4.4.5 and Client to 4.5.2
                 Key: WFLY-9627
                 URL: https://issues.jboss.org/browse/WFLY-9627
             Project: WildFly
          Issue Type: Component Upgrade
            Reporter: Romain Pelisse
            Assignee: Jason Greene


Some utility classes have disappeared in the recent version of both librairies, which means some small part of the testsuite code needs to be modified to allow the upgrade.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 12:48:00 2017
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Wed, 20 Dec 2017 12:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9627) Update Http Core to 4.4.5 and
 Client to 4.5.2
In-Reply-To: <JIRA.12725779.1513791965000@Atlassian.JIRA>
References: <JIRA.12725779.1513791965000@Atlassian.JIRA>
	<JIRA.12725779.1513791965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725779.1513791965000.10921.1513792080275@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Romain Pelisse reassigned WFLY-9627:
------------------------------------

    Assignee: Romain Pelisse  (was: Jason Greene)


> Update Http Core to 4.4.5 and Client to 4.5.2
> ---------------------------------------------
>
>                 Key: WFLY-9627
>                 URL: https://issues.jboss.org/browse/WFLY-9627
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Romain Pelisse
>            Assignee: Romain Pelisse
>
> Some utility classes have disappeared in the recent version of both librairies, which means some small part of the testsuite code needs to be modified to allow the upgrade.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 12:49:00 2017
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Wed, 20 Dec 2017 12:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9627) Update Http Core to 4.4.5 and
 Client to 4.5.4
In-Reply-To: <JIRA.12725779.1513791965000@Atlassian.JIRA>
References: <JIRA.12725779.1513791965000@Atlassian.JIRA>
	<JIRA.12725779.1513791965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725779.1513791965000.10927.1513792140064@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Romain Pelisse updated WFLY-9627:
---------------------------------
    Summary: Update Http Core to 4.4.5 and Client to 4.5.4  (was: Update Http Core to 4.4.5 and Client to 4.5.2)


> Update Http Core to 4.4.5 and Client to 4.5.4
> ---------------------------------------------
>
>                 Key: WFLY-9627
>                 URL: https://issues.jboss.org/browse/WFLY-9627
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Romain Pelisse
>            Assignee: Romain Pelisse
>
> Some utility classes have disappeared in the recent version of both librairies, which means some small part of the testsuite code needs to be modified to allow the upgrade.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 12:52:00 2017
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Wed, 20 Dec 2017 12:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9627) Update Http Core to 4.4.5 and
 Client to 4.5.4
In-Reply-To: <JIRA.12725779.1513791965000@Atlassian.JIRA>
References: <JIRA.12725779.1513791965000@Atlassian.JIRA>
	<JIRA.12725779.1513791965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725779.1513791965000.10936.1513792320103@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Romain Pelisse updated WFLY-9627:
---------------------------------
    Description: 
Some utility classes have disappeared in the recent version of both librairies, which means some small part of the testsuite code needs to be modified to allow the upgrade.

Note: the upgrade needs to be peform on Wildfly Core but the code changes needed are in Wildfly.

  was:Some utility classes have disappeared in the recent version of both librairies, which means some small part of the testsuite code needs to be modified to allow the upgrade.



> Update Http Core to 4.4.5 and Client to 4.5.4
> ---------------------------------------------
>
>                 Key: WFLY-9627
>                 URL: https://issues.jboss.org/browse/WFLY-9627
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Romain Pelisse
>            Assignee: Romain Pelisse
>
> Some utility classes have disappeared in the recent version of both librairies, which means some small part of the testsuite code needs to be modified to allow the upgrade.
> Note: the upgrade needs to be peform on Wildfly Core but the code changes needed are in Wildfly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 12:53:00 2017
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Wed, 20 Dec 2017 12:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3473) Update Http Core to 4.4.5
 and Client to 4.5.4
In-Reply-To: <JIRA.12725781.1513792350000@Atlassian.JIRA>
References: <JIRA.12725781.1513792350000@Atlassian.JIRA>
	<JIRA.12725781.1513792350858@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725781.1513792350000.10939.1513792380285@Atlassian.JIRA>

Romain Pelisse created WFCORE-3473:
--------------------------------------

             Summary: Update Http Core to 4.4.5 and Client to 4.5.4
                 Key: WFCORE-3473
                 URL: https://issues.jboss.org/browse/WFCORE-3473
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Romain Pelisse
            Assignee: Romain Pelisse






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 12:55:06 2017
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Wed, 20 Dec 2017 12:55:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3473) Update Http Core to 4.4.5
 and Client to 4.5.4
In-Reply-To: <JIRA.12725781.1513792351000@Atlassian.JIRA>
References: <JIRA.12725781.1513792351000@Atlassian.JIRA>
	<JIRA.12725781.1513792351000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725781.1513792351000.11024.1513792506046@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Romain Pelisse updated WFCORE-3473:
-----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3004


> Update Http Core to 4.4.5 and Client to 4.5.4
> ---------------------------------------------
>
>                 Key: WFCORE-3473
>                 URL: https://issues.jboss.org/browse/WFCORE-3473
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Romain Pelisse
>            Assignee: Romain Pelisse
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 13:48:00 2017
From: issues at jboss.org (Pedro Almeida (JIRA))
Date: Wed, 20 Dec 2017 13:48: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.1513795667244@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.11086.1513795680256@Atlassian.JIRA>

Pedro Almeida created DROOLS-2194:
-------------------------------------

             Summary: 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  Wed Dec 20 15:24:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 20 Dec 2017 15:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3474) Remove
	CoreManagementRootResourceAdd
In-Reply-To: <JIRA.12725795.1513801399000@Atlassian.JIRA>
References: <JIRA.12725795.1513801399000@Atlassian.JIRA>
	<JIRA.12725795.1513801399466@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725795.1513801399000.11427.1513801440153@Atlassian.JIRA>

Brian Stansberry created WFCORE-3474:
----------------------------------------

             Summary: Remove CoreManagementRootResourceAdd
                 Key: WFCORE-3474
                 URL: https://issues.jboss.org/browse/WFCORE-3474
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


CoreManagementRootResourceAdd is just a subclass of AbstractAddStepHandler with no additional code. So just use the superclass.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 15:27:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 20 Dec 2017 15:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3474) Remove
	CoreManagementRootResourceAdd
In-Reply-To: <JIRA.12725795.1513801399000@Atlassian.JIRA>
References: <JIRA.12725795.1513801399000@Atlassian.JIRA>
	<JIRA.12725795.1513801399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725795.1513801399000.11430.1513801620098@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3474:
-------------------------------------
    Description: CoreManagementRootResourceAdd is a subclass of AbstractAddStepHandler with no additional code. So just use the superclass.  (was: CoreManagementRootResourceAdd is just a subclass of AbstractAddStepHandler with no additional code. So just use the superclass.)


> Remove CoreManagementRootResourceAdd
> ------------------------------------
>
>                 Key: WFCORE-3474
>                 URL: https://issues.jboss.org/browse/WFCORE-3474
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> CoreManagementRootResourceAdd is a subclass of AbstractAddStepHandler with no additional code. So just use the superclass.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 16:57:00 2017
From: issues at jboss.org (Gunnar Morling (JIRA))
Date: Wed, 20 Dec 2017 16:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9628) Bean Validation 2.0 Support
In-Reply-To: <JIRA.12725803.1513806985000@Atlassian.JIRA>
References: <JIRA.12725803.1513806985000@Atlassian.JIRA>
	<JIRA.12725803.1513806985172@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725803.1513806985000.11533.1513807020100@Atlassian.JIRA>

Gunnar Morling created WFLY-9628:
------------------------------------

             Summary: Bean Validation 2.0 Support
                 Key: WFLY-9628
                 URL: https://issues.jboss.org/browse/WFLY-9628
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Gunnar Morling
            Assignee: Jason Greene






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Dec 20 18:08:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 20 Dec 2017 18:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3475) Tighten visibility on some
 AttributeDefinition fields
In-Reply-To: <JIRA.12725805.1513811265000@Atlassian.JIRA>
References: <JIRA.12725805.1513811265000@Atlassian.JIRA>
	<JIRA.12725805.1513811265577@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725805.1513811265000.11721.1513811280074@Atlassian.JIRA>

Brian Stansberry created WFCORE-3475:
----------------------------------------

             Summary: 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
            Priority: Minor


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  Thu Dec 21 03:32:00 2017
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Thu, 21 Dec 2017 03:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9625) Exception on Weld during
 inicialization of CDI/EJB bean on IBM JDK
In-Reply-To: <JIRA.12725702.1513771222000@Atlassian.JIRA>
References: <JIRA.12725702.1513771222000@Atlassian.JIRA>
	<JIRA.12725702.1513771222000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725702.1513771222000.12677.1513845120288@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507735#comment-13507735 ] 

Matej Novotny commented on WFLY-9625:
-------------------------------------

Alright, then it is as IBM issue states - fixed in 8.0.5.6+.
Therefore I think this issue isn't a blocker and should in fact be closed, agreed?

> Exception on Weld during inicialization of CDI/EJB bean on IBM JDK
> ------------------------------------------------------------------
>
>                 Key: WFLY-9625
>                 URL: https://issues.jboss.org/browse/WFLY-9625
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB
>            Reporter: Marek Kopeck?
>            Assignee: Martin Kouba
>            Priority: Blocker
>
> *Description of problem:*
> Exception on Weld during inicialization of CDI/EJB bean on IBM JDK
> Example of beans:
> {code:java}
> @RequestScoped
> public class LoggingBean {
>     static {
>         System.out.println("something");
>     }
> }
> {code}
> {code:java}
> @Singleton
> @Startup
> public class LoggingBean {
>     static {
>         System.out.println("something");
>     }
> }
> {code}
> *How reproducible:*
> Always on IBM JDK
> *Steps to Reproduce:*
> # Deploy deployment with beans from description
> *Actual results:*
> CDI bean:
> {noformat}
> 12:49:05,070 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /home/mkopecky/git/wfly.05/standalone/data/content/f8/f08bc0eb9dd3893743634459d1218cdbfeb4ac/content
> 12:49:05,081 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.jar" (runtime-name: "test.jar")
> 12:49:05,234 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0003: Processing weld deployment test.jar
> 12:49:05,257 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-5) HV000001: Hibernate Validator 5.3.5.Final
> 12:49:05,358 INFO  [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 3.0.2 (Final)
> 12:49:05,505 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Chakra' 8.2.8.Final
> 12:49:05,625 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."test.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.jar".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1687)
> 	at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.<clinit>(ObserverNotifier.java:480)
> 	at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
> 	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
> 	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> 	at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
> 	at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
> 	at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> 	at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1695)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1674)
> 	... 4 more
> Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at java.lang.invoke.MethodHandles$Lookup.checkClassAccess(MethodHandles.java:371)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:281)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:264)
> 	at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:468)
> 	at java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:966)
> 	at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
> 	at java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:856)
> 	... 16 more
> 12:49:05,734 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 20) WFLYCLINF0002: Started client-mappings cache from ejb container
> 12:49:05,772 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "test.jar"}) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]"]
> }
> 12:49:05,774 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "test.jar" was rolled back with the following failure message: 
> {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]"]
> }
> 12:49:05,791 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment test.jar (runtime-name: test.jar) in 17ms
> {noformat}
> EJB bean
> {noformat}
> 12:37:04,047 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /home/mkopecky/git/wfly.05/standalone/data/content/fd/828118f8edbfcb42f98f3518dcc46baae85eaa/content
> 12:37:04,061 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.jar" (runtime-name: "test.jar")
> 12:37:04,238 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0003: Processing weld deployment test.jar
> 12:37:04,270 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.3.5.Final
> 12:37:04,319 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-2) WFLYEJB0473: JNDI bindings for session bean named 'LoggingBean' in deployment unit 'deployment "test.jar"' are as follows:
> 	java:global/test/LoggingBean!org.jboss.test.LoggingBean
> 	java:app/test/LoggingBean!org.jboss.test.LoggingBean
> 	java:module/LoggingBean!org.jboss.test.LoggingBean
> 	java:global/test/LoggingBean
> 	java:app/test/LoggingBean
> 	java:module/LoggingBean
> 12:37:04,387 INFO  [stdout] (MSC service thread 1-7) something
> 12:37:04,428 INFO  [org.jboss.weld.Version] (MSC service thread 1-7) WELD-000900: 3.0.2 (Final)
> 12:37:04,544 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Chakra' 8.2.8.Final
> 12:37:04,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."test.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.jar".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1687)
> 	at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.<clinit>(ObserverNotifier.java:480)
> 	at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
> 	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
> 	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> 	at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
> 	at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
> 	at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> 	at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1695)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1674)
> 	... 4 more
> Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at java.lang.invoke.MethodHandles$Lookup.checkClassAccess(MethodHandles.java:371)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:281)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:264)
> 	at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:468)
> 	at java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:966)
> 	at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
> 	at java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:856)
> 	... 16 more
> 12:37:04,774 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) WFLYCLINF0002: Started client-mappings cache from ejb container
> 12:37:04,814 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "test.jar"}) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator",
>         "jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"
>     ],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator]",
>         "jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService]",
>         "jboss.deployment.unit.\"test.jar\".deploymentCompleteService is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]",
>         "jboss.deployment.unit.\"test.jar\".moduleDeploymentRuntimeInformationStart is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]"
>     ]
> }
> 12:37:04,815 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "test.jar" was rolled back with the following failure message: 
> {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator",
>         "jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"
>     ],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator]",
>         "jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService]",
>         "jboss.deployment.unit.\"test.jar\".deploymentCompleteService is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]",
>         "jboss.deployment.unit.\"test.jar\".moduleDeploymentRuntimeInformationStart is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]"
>     ]
> }
> 12:37:04,830 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0028: Stopped deployment test.jar (runtime-name: test.jar) in 14ms
> {noformat}
> *Expected results:*
> no errors



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Dec 21 04:06:00 2017
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Thu, 21 Dec 2017 04:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3476) ServerSuspendHandler gets
 stuck suspending a server already suspended if a timeout is used
In-Reply-To: <JIRA.12725819.1513847134000@Atlassian.JIRA>
References: <JIRA.12725819.1513847134000@Atlassian.JIRA>
	<JIRA.12725819.1513847134880@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725819.1513847134000.12786.1513847160265@Atlassian.JIRA>

Yeray Borges created WFCORE-3476:
------------------------------------

             Summary: ServerSuspendHandler gets stuck suspending a server already suspended if a timeout is used
                 Key: WFCORE-3476
                 URL: https://issues.jboss.org/browse/WFCORE-3476
             Project: WildFly Core
          Issue Type: Bug
    Affects Versions: 4.0.0.Alpha5
            Reporter: Yeray Borges
            Assignee: Yeray Borges


ServerSuspendHandler blocks until the suspend is done receiving a notification from the SuspendController. The issue here is if the server is already suspended, there are no notifications, and then the handler blocks forever until it is interrupted. This only occurs if the suspend is used with a timeout.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 04:09:00 2017
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Thu, 21 Dec 2017 04:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3476) ServerSuspendHandler gets
 stuck suspending a server already suspended if a timeout is used
In-Reply-To: <JIRA.12725819.1513847135000@Atlassian.JIRA>
References: <JIRA.12725819.1513847135000@Atlassian.JIRA>
	<JIRA.12725819.1513847135000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725819.1513847135000.12802.1513847340070@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges updated WFCORE-3476:
---------------------------------
    Steps to Reproduce: 
# For example, in domain mode, execute:
:suspend-servers
# Once the servers are suspended, run again: 
:suspend-servers(timeout=10)

The latest operation never ends

  was:
# For example, in domain mode, execute:
:suspend-servers
# wait some seconds until getting the servers in a suspended state, run again: 
:suspend-servers(timeout=10)

The latest operation never ends



> ServerSuspendHandler gets stuck suspending a server already suspended if a timeout is used
> ------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3476
>                 URL: https://issues.jboss.org/browse/WFCORE-3476
>             Project: WildFly Core
>          Issue Type: Bug
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Yeray Borges
>            Assignee: Yeray Borges
>
> ServerSuspendHandler blocks until the suspend is done receiving a notification from the SuspendController. The issue here is if the server is already suspended, there are no notifications, and then the handler blocks forever until it is interrupted. This only occurs if the suspend is used with a timeout.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 04:10:00 2017
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Thu, 21 Dec 2017 04:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3476) ServerSuspendHandler gets
 stuck suspending a server already suspended if a timeout is used
In-Reply-To: <JIRA.12725819.1513847135000@Atlassian.JIRA>
References: <JIRA.12725819.1513847135000@Atlassian.JIRA>
	<JIRA.12725819.1513847135000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725819.1513847135000.12804.1513847400093@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges updated WFCORE-3476:
---------------------------------
    Description: 
ServerSuspendHandler blocks until the suspend is done receiving a notification from the SuspendController. The issue here is if the server is already suspended, there are no notifications, and then the handler blocks forever until it is interrupted. This only occurs if the suspend is used with a timeout for a server already suspended.


  was:
ServerSuspendHandler blocks until the suspend is done receiving a notification from the SuspendController. The issue here is if the server is already suspended, there are no notifications, and then the handler blocks forever until it is interrupted. This only occurs if the suspend is used with a timeout.




> ServerSuspendHandler gets stuck suspending a server already suspended if a timeout is used
> ------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3476
>                 URL: https://issues.jboss.org/browse/WFCORE-3476
>             Project: WildFly Core
>          Issue Type: Bug
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Yeray Borges
>            Assignee: Yeray Borges
>
> ServerSuspendHandler blocks until the suspend is done receiving a notification from the SuspendController. The issue here is if the server is already suspended, there are no notifications, and then the handler blocks forever until it is interrupted. This only occurs if the suspend is used with a timeout for a server already suspended.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 04:31:00 2017
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Thu, 21 Dec 2017 04:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3476) ServerSuspendHandler gets
 stuck suspending a server already suspended if a timeout is used
In-Reply-To: <JIRA.12725819.1513847135000@Atlassian.JIRA>
References: <JIRA.12725819.1513847135000@Atlassian.JIRA>
	<JIRA.12725819.1513847135000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725819.1513847135000.12937.1513848660205@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges updated WFCORE-3476:
---------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3007


> ServerSuspendHandler gets stuck suspending a server already suspended if a timeout is used
> ------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3476
>                 URL: https://issues.jboss.org/browse/WFCORE-3476
>             Project: WildFly Core
>          Issue Type: Bug
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Yeray Borges
>            Assignee: Yeray Borges
>
> ServerSuspendHandler blocks until the suspend is done receiving a notification from the SuspendController. The issue here is if the server is already suspended, there are no notifications, and then the handler blocks forever until it is interrupted. This only occurs if the suspend is used with a timeout for a server already suspended.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 05:02:00 2017
From: issues at jboss.org (Nazibur Rahman (JIRA))
Date: Thu, 21 Dec 2017 05:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9629) I am using WildFly 10 and
 getting bellow errors. I used Mysql database.
In-Reply-To: <JIRA.12725823.1513850508000@Atlassian.JIRA>
References: <JIRA.12725823.1513850508000@Atlassian.JIRA>
	<JIRA.12725823.1513850508802@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725823.1513850508000.13029.1513850520553@Atlassian.JIRA>

Nazibur Rahman created WFLY-9629:
------------------------------------

             Summary: I am using WildFly 10 and getting bellow errors. I used Mysql database.
                 Key: WFLY-9629
                 URL: https://issues.jboss.org/browse/WFLY-9629
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Nazibur Rahman
            Assignee: Jason Greene


15:21:20,308 INFO  [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
15:21:20,776 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
15:21:20,971 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) starting
15:21:23,156 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0004: Found Paladion_web.war in deployment directory. To trigger deployment create a file called Paladion_web.war.dodeploy
15:21:23,227 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
15:21:23,264 INFO  [org.xnio] (MSC service thread 1-5) XNIO version 3.4.0.Final
15:21:23,285 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.4.0.Final
15:21:23,378 INFO  [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 4.0.21.Final
15:21:23,408 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 38) WFLYCLINF0001: Activating Infinispan subsystem.
15:21:23,436 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 37) WFLYIO001: Worker 'default' has auto-configured to 8 core threads with 64 task threads based on your 4 available processors
15:21:23,487 WARN  [org.jboss.as.txn] (ServerService Thread Pool -- 54) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
15:21:23,505 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 56) WFLYWS0002: Activating WebServices Extension
15:21:23,709 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 53) WFLYSEC0002: Activating Security Subsystem
15:21:23,573 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 46) WFLYNAM0001: Activating Naming Subsystem
15:21:23,712 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 44) WFLYJSF0007: Activated the following JSF Implementations: [main]
15:21:23,764 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0003: Undertow 1.4.0.Final starting
15:21:23,771 INFO  [org.jboss.as.connector] (MSC service thread 1-5) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.3.4.Final)
15:21:23,767 INFO  [org.jboss.as.security] (MSC service thread 1-7) WFLYSEC0001: Current PicketBox version=4.9.6.Final
15:21:23,935 INFO  [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service
15:21:23,936 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-3) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
15:21:23,998 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 33) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
15:21:24,098 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0018: Started Driver service with driver-name = h2
15:21:24,283 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 55) WFLYUT0014: Creating file handler for path '/opt/wildfly-10.1.0.Final/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
15:21:24,399 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0012: Started server default-server.
15:21:24,408 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0018: Host default-host starting
15:21:24,683 INFO  [org.jboss.as.ejb3] (MSC service thread 1-8) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 64 (per class), which is derived from thread worker pool sizing.
15:21:24,685 INFO  [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 16 (per class), which is derived from the number of CPUs on this host.
15:21:24,811 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8080
15:21:25,543 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
15:21:25,571 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-5) WFLYDM0111: Keystore /opt/wildfly-10.1.0.Final/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
15:21:25,691 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) WFLYDS0013: Started FileSystemDeploymentService for directory /opt/wildfly-10.1.0.Final/standalone/deployments
15:21:25,708 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "Paladion_web.war" (runtime-name: "Paladion_web.war")
15:21:26,127 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-8) ISPN000128: Infinispan version: Infinispan 'Chakra' 8.2.4.Final
15:21:26,289 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 60) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
15:21:26,289 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 62) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
15:21:26,291 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 60) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
15:21:26,292 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 62) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
15:21:26,265 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 61) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
15:21:26,301 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 61) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
15:21:26,609 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTPS listener https listening on 127.0.0.1:8443
15:21:26,851 INFO  [org.jboss.ws.common.management] (MSC service thread 1-5) JBWS022052: Starting JBossWS 5.1.5.Final (Apache CXF 3.1.6) 
15:21:29,164 INFO  [org.jboss.as.protocol] (management I/O-1) WFLYPRT0057:  cancelled task by interrupting thread Thread[management-handler-thread - 3,5,management-handler-thread]
15:21:30,857 WARN  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry activation.jar in /opt/wildfly-10.1.0.Final/standalone/deployments/Paladion_web.war/WEB-INF/lib/mail-1.4.jar  does not point to a valid jar for a Class-Path reference.
15:21:31,482 INFO  [org.jboss.as.jpa] (MSC service thread 1-8) WFLYJPA0002: Read persistence.xml for Paladion_dao
15:21:31,819 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 61) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'Paladion_web.war#Paladion_dao'
15:21:31,836 INFO  [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 61) HHH000204: Processing PersistenceUnitInfo [
	name: Paladion_dao
	...]
15:21:32,071 INFO  [org.hibernate.Version] (ServerService Thread Pool -- 61) HHH000412: Hibernate Core {5.0.10.Final}
15:21:32,075 INFO  [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 61) HHH000206: hibernate.properties not found
15:21:32,079 INFO  [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 61) HHH000021: Bytecode provider name : javassist
15:21:32,167 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0003: Processing weld deployment Paladion_web.war
15:21:32,194 INFO  [org.hibernate.annotations.common.Version] (ServerService Thread Pool -- 61) HCANN000001: Hibernate Commons Annotations {5.0.1.Final}
15:21:32,434 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.2.4.Final
15:21:32,892 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0005: Deploying non-JDBC-compliant driver class org.mariadb.jdbc.Driver (version 1.1)
15:21:32,905 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0005: Deploying non-JDBC-compliant driver class com.mysql.jdbc.Driver (version 5.1)
15:21:32,968 INFO  [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 2.3.5 (Final)
15:21:33,023 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0018: Started Driver service with driver-name = Paladion_web.war_org.mariadb.jdbc.Driver_1_1
15:21:33,023 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-6) WFLYJCA0018: Started Driver service with driver-name = Paladion_web.war_com.mysql.jdbc.Driver_5_1
15:21:33,342 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 61) WFLYJPA0010: Starting Persistence Unit (phase 2 of 2) Service 'Paladion_web.war#Paladion_dao'
15:21:33,790 INFO  [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 61) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
15:21:33,804 WARN  [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 61) HHH000431: Unable to determine H2 database version, certain features may not work
15:21:33,882 INFO  [org.hibernate.envers.boot.internal.EnversServiceImpl] (ServerService Thread Pool -- 61) Envers integration enabled? : true
15:21:35,628 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.persistenceunit."Paladion_web.war#Paladion_dao": org.jboss.msc.service.StartException in service jboss.persistenceunit."Paladion_web.war#Paladion_dao": java.lang.AbstractMethodError
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:179)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:121)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:193)
	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)
Caused by: java.lang.AbstractMethodError
	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:278)
	at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
	at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:161)
	... 7 more

15:21:35,639 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "Paladion_web.war")]) - failure description: {
    "WFLYCTL0080: Failed services" => {"jboss.persistenceunit.\"Paladion_web.war#Paladion_dao\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"Paladion_web.war#Paladion_dao\": java.lang.AbstractMethodError
    Caused by: java.lang.AbstractMethodError"},
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.persistenceunit.\"Paladion_web.war#Paladion_dao\""],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
15:21:35,703 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 34) WFLYSRV0010: Deployed "Paladion_web.war" (runtime-name : "Paladion_web.war")
15:21:35,710 INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
WFLYCTL0186:   Services which failed to start:      service jboss.persistenceunit."Paladion_web.war#Paladion_dao": org.jboss.msc.service.StartException in service jboss.persistenceunit."Paladion_web.war#Paladion_dao": java.lang.AbstractMethodError

15:21:35,858 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
15:21:35,858 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
15:21:35,858 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started (with errors) in 16259ms - Started 503 of 832 services (80 services failed or missing dependencies, 404 services are lazy, passive or on-demand)
15:21:35,902 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0019: Stopped Driver service with driver-name = Paladion_web.war_org.mariadb.jdbc.Driver_1_1
15:21:35,903 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0019: Stopped Driver service with driver-name = Paladion_web.war_com.mysql.jdbc.Driver_5_1
15:21:35,912 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 61) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'Paladion_web.war#Paladion_dao'
15:21:36,015 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment Paladion_web.war (runtime-name: Paladion_web.war) in 125ms
15:21:36,088 WARN  [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0357: Notification of type deployment-undeployed is not described for the resource at the address []
15:21:36,090 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0009: Undeployed "Paladion_web.war" (runtime-name: "Paladion_web.war")
15:21:36,095 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report
WFLYCTL0184:    New missing/unsatisfied dependencies:
      service jboss.deployment.unit."Paladion_web.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.OptionsTag".WeldInstantiator, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.HiddenInputTag".WeldInstantiator, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator, WFLYCTL0208: ... and 27 more ] 
      service jboss.deployment.unit."Paladion_web.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.OptionsTag".WeldInstantiator, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.HiddenInputTag".WeldInstantiator, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator, WFLYCTL0208: ... and 36 more ] 
      service jboss.deployment.unit."Paladion_web.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."com.sun.faces.config.ConfigureListener".START] 
      service jboss.deployment.unit."Paladion_web.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."com.sun.faces.config.ConfigureListener".START] 
      service jboss.deployment.unit."Paladion_web.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."javax.faces.webapp.FacetTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."javax.faces.webapp.FacetTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."javax.faces.webapp.FacetTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] 
      service jboss.deployment.unit."Paladion_web.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] 
      service jboss.deployment.unit."Paladion_web.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] 
      service jboss.deployment.unit."Paladion_web.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] 
      service jboss.deployment.unit."Paladion_web.war".component."net.bull.javamelody.MonitoringFilter".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."net.bull.javamelody.MonitoringFilter".START] 
      service jboss.deployment.unit."Paladion_web.war".component."net.bull.javamelody.MonitoringFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."net.bull.javamelody.MonitoringFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."net.bull.javamelody.MonitoringFilter".START] 
      service jboss.deployment.unit."Paladion_web.war".component."net.bull.javamelody.SessionListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.jboss.weld.servlet.WeldInitialListener".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.jboss.weld.servlet.WeldInitialListener".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.http.server.ServletServerHttpAsyncRequestControl".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.http.server.ServletServerHttpAsyncRequestControl".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.http.server.ServletServerHttpAsyncRequestControl".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.http.server.ServletServerHttpAsyncRequestControl".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.http.server.ServletServerHttpAsyncRequestControl".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ArgumentTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ArgumentTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ArgumentTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ArgumentTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ArgumentTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.BindErrorsTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.BindTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.BindTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.BindTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.BindTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.BindTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.EscapeBodyTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.EvalTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.EvalTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.EvalTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.HtmlEscapeTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.HtmlEscapeTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.HtmlEscapeTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.HtmlEscapeTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.HtmlEscapeTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.MessageTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.MessageTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.MessageTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.MessageTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.MessageTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.NestedPathTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.NestedPathTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.NestedPathTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.NestedPathTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.NestedPathTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ParamTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ParamTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ParamTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ParamTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ParamTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ThemeTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ThemeTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ThemeTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ThemeTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ThemeTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.TransformTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.TransformTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.TransformTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.TransformTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.TransformTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.UrlTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.UrlTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.UrlTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.UrlTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.UrlTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.ButtonTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.ButtonTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.ButtonTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.ButtonTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.ButtonTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.CheckboxTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.CheckboxTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.CheckboxTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.CheckboxTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.CheckboxTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.CheckboxesTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.CheckboxesTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.CheckboxesTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.CheckboxesTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.CheckboxesTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.ErrorsTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.ErrorsTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.ErrorsTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.ErrorsTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.ErrorsTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.FormTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.FormTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.FormTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.FormTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.FormTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.HiddenInputTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.HiddenInputTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.HiddenInputTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.InputTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.InputTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.InputTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.InputTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.InputTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.LabelTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.OptionTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.OptionTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.OptionTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.OptionTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.OptionTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.OptionsTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.OptionsTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.OptionsTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.PasswordInputTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.PasswordInputTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.PasswordInputTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.PasswordInputTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.PasswordInputTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.RadioButtonTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.RadioButtonTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.RadioButtonTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.RadioButtonTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.RadioButtonTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.RadioButtonsTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.RadioButtonsTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.RadioButtonsTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.RadioButtonsTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.RadioButtonsTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.SelectTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.SelectTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.SelectTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.TextareaTag".CREATE (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.TextareaTag".START] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.TextareaTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService, service jboss.undertow.deployment.default-server.default-host./Paladion_web, service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.TextareaTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.TextareaTag".START] 
      service jboss.deployment.unit."Paladion_web.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService] 
      service jboss.deployment.unit."Paladion_web.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.LabelTag".START, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ThemeTag".START, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.HiddenInputTag".START, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ArgumentTag".START, WFLYCTL0208: ... and 34 more ] 
      service jboss.persistenceunit."Paladion_web.war#Paladion_dao" (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.LabelTag".START, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ThemeTag".START, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.form.HiddenInputTag".START, service jboss.deployment.unit."Paladion_web.war".component."org.springframework.web.servlet.tags.ArgumentTag".START, WFLYCTL0208: ... and 35 more ] 
      service jboss.undertow.deployment.default-server.default-host./Paladion_web (missing) dependents: [service jboss.deployment.unit."Paladion_web.war".deploymentCompleteService] 
      service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web] 
      service jboss.undertow.deployment.default-server.default-host./Paladion_web.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService] 
      service jboss.undertow.deployment.default-server.default-host./Paladion_web.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService] 
      service org.wildfly.request-controller.control-point."Paladion_web.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./Paladion_web.UndertowDeploymentInfoService] 
WFLYCTL0186:   Services which failed to start:      service jboss.persistenceunit."Paladion_web.war#Paladion_dao"

15:21:40,754 INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) WFLYDS0004: Found Paladion_web.war in deployment directory. To trigger deployment create a file called Paladion_web.war.dodeploy




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 05:26:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 05:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3477) Add EAP 7.1.0 configs to
 ParseAndMarshalModelTestCase
In-Reply-To: <JIRA.12725824.1513851940000@Atlassian.JIRA>
References: <JIRA.12725824.1513851940000@Atlassian.JIRA>
	<JIRA.12725824.1513851940147@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725824.1513851940000.13079.1513851960118@Atlassian.JIRA>

Kabir Khan created WFCORE-3477:
----------------------------------

             Summary: Add EAP 7.1.0 configs to ParseAndMarshalModelTestCase
                 Key: WFCORE-3477
                 URL: https://issues.jboss.org/browse/WFCORE-3477
             Project: WildFly Core
          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  Thu Dec 21 05:27:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 05:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9630) Add EAP 7.1.0 configs to
 ParseAndMarshalModelTestCase
In-Reply-To: <JIRA.12725824.1513851940000@Atlassian.JIRA>
References: <JIRA.12725824.1513851940000@Atlassian.JIRA>
	<JIRA.12725824.1513851940000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725824.1513851940000.13084.1513852020312@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan moved WFCORE-3477 to WFLY-9630:
------------------------------------------

        Project: WildFly  (was: WildFly Core)
            Key: WFLY-9630  (was: WFCORE-3477)
    Component/s: Domain Management
                 Test Suite
                     (was: Domain Management)
                     (was: Test Suite)


> Add EAP 7.1.0 configs to ParseAndMarshalModelTestCase
> -----------------------------------------------------
>
>                 Key: WFLY-9630
>                 URL: https://issues.jboss.org/browse/WFLY-9630
>             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  Thu Dec 21 06:12:00 2017
From: issues at jboss.org (=?UTF-8?Q?Mari=C3=A1n_Macik_=28JIRA=29?=)
Date: Thu, 21 Dec 2017 06:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9631) "Failed to reinstate timer"
 warning is shown when creating large number of EJB timers
In-Reply-To: <JIRA.12725827.1513854705000@Atlassian.JIRA>
References: <JIRA.12725827.1513854705000@Atlassian.JIRA>
	<JIRA.12725827.1513854705202@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725827.1513854705000.13188.1513854720137@Atlassian.JIRA>

Mari?n Macik created WFLY-9631:
----------------------------------

             Summary: "Failed to reinstate timer" warning is shown when creating large number of EJB timers
                 Key: WFLY-9631
                 URL: https://issues.jboss.org/browse/WFLY-9631
             Project: WildFly
          Issue Type: Bug
          Components: EJB
         Environment: EAP 7.0.8.GA
Oracle 12 c
[Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27623949f3cafd0e11828bce8a93de21/jboss-eap-7.0/standalone/configuration/standalone-full.xml#L142-L205] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
            Reporter: Mari?n Macik
            Assignee: Matej Novotny


Hi, [~manovotn],

as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.

What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:


{code:java}
WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
    at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
    at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
    at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
    at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
    at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
{code}

The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.

Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.

So I think it has something to do with refresh interval.

Can you please have a look at it?

Thank you very much!

Marian Macik



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Dec 21 06:21:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 21 Dec 2017 06:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2195) CCE when modifying a
 declared type during an incremental update
In-Reply-To: <JIRA.12725829.1513855199000@Atlassian.JIRA>
References: <JIRA.12725829.1513855199000@Atlassian.JIRA>
	<JIRA.12725829.1513855199804@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725829.1513855199000.13213.1513855260327@Atlassian.JIRA>

Mario Fusco created DROOLS-2195:
-----------------------------------

             Summary: CCE when modifying a declared type during an incremental update
                 Key: DROOLS-2195
                 URL: https://issues.jboss.org/browse/DROOLS-2195
             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 Dec 21 06:25:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 21 Dec 2017 06:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2195) CCE when modifying a
 declared type during an incremental update
In-Reply-To: <JIRA.12725829.1513855200000@Atlassian.JIRA>
References: <JIRA.12725829.1513855200000@Atlassian.JIRA>
	<JIRA.12725829.1513855200000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725829.1513855200000.13225.1513855500065@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507788#comment-13507788 ] 

Mario Fusco commented on DROOLS-2195:
-------------------------------------

Creating a FactType of a given declared type after that it has been updated during an incremental compilation causes the following ClassCastException

{code}
Caused by: java.lang.ClassCastException: org.drools.example.api.kiemodulemodel.Message cannot be cast to org.drools.example.api.kiemodulemodel.Message
	at org.drools.base.org.drools.example.api.kiemodulemodel.Message779598031$setName.setValue(Unknown Source)
	at org.drools.core.base.ClassFieldWriter.setValue(ClassFieldWriter.java:164)
	at org.drools.core.base.ClassFieldAccessor.setValue(ClassFieldAccessor.java:246)
	at org.drools.core.factmodel.ClassDefinition.set(ClassDefinition.java:272)
{code}

> CCE when modifying a declared type during an incremental update
> ---------------------------------------------------------------
>
>                 Key: DROOLS-2195
>                 URL: https://issues.jboss.org/browse/DROOLS-2195
>             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 Dec 21 06:40:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 21 Dec 2017 06:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9625) Exception on Weld during
 inicialization of CDI/EJB bean on IBM JDK
In-Reply-To: <JIRA.12725702.1513771222000@Atlassian.JIRA>
References: <JIRA.12725702.1513771222000@Atlassian.JIRA>
	<JIRA.12725702.1513771222000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725702.1513771222000.13289.1513856400380@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba resolved WFLY-9625.
--------------------------------
    Resolution: Rejected


This is an IBM JVM issue - see also http://www-01.ibm.com/support/docview.wss?uid=swg1IJ02283, and should be fixed in 8 SR5 FP6 (8.0.5.6).

> Exception on Weld during inicialization of CDI/EJB bean on IBM JDK
> ------------------------------------------------------------------
>
>                 Key: WFLY-9625
>                 URL: https://issues.jboss.org/browse/WFLY-9625
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB
>            Reporter: Marek Kopeck?
>            Assignee: Martin Kouba
>            Priority: Blocker
>
> *Description of problem:*
> Exception on Weld during inicialization of CDI/EJB bean on IBM JDK
> Example of beans:
> {code:java}
> @RequestScoped
> public class LoggingBean {
>     static {
>         System.out.println("something");
>     }
> }
> {code}
> {code:java}
> @Singleton
> @Startup
> public class LoggingBean {
>     static {
>         System.out.println("something");
>     }
> }
> {code}
> *How reproducible:*
> Always on IBM JDK
> *Steps to Reproduce:*
> # Deploy deployment with beans from description
> *Actual results:*
> CDI bean:
> {noformat}
> 12:49:05,070 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /home/mkopecky/git/wfly.05/standalone/data/content/f8/f08bc0eb9dd3893743634459d1218cdbfeb4ac/content
> 12:49:05,081 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.jar" (runtime-name: "test.jar")
> 12:49:05,234 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0003: Processing weld deployment test.jar
> 12:49:05,257 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-5) HV000001: Hibernate Validator 5.3.5.Final
> 12:49:05,358 INFO  [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 3.0.2 (Final)
> 12:49:05,505 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Chakra' 8.2.8.Final
> 12:49:05,625 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."test.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.jar".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1687)
> 	at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.<clinit>(ObserverNotifier.java:480)
> 	at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
> 	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
> 	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> 	at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
> 	at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
> 	at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> 	at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1695)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1674)
> 	... 4 more
> Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at java.lang.invoke.MethodHandles$Lookup.checkClassAccess(MethodHandles.java:371)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:281)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:264)
> 	at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:468)
> 	at java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:966)
> 	at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
> 	at java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:856)
> 	... 16 more
> 12:49:05,734 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 20) WFLYCLINF0002: Started client-mappings cache from ejb container
> 12:49:05,772 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "test.jar"}) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]"]
> }
> 12:49:05,774 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "test.jar" was rolled back with the following failure message: 
> {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]"]
> }
> 12:49:05,791 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment test.jar (runtime-name: test.jar) in 17ms
> {noformat}
> EJB bean
> {noformat}
> 12:37:04,047 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /home/mkopecky/git/wfly.05/standalone/data/content/fd/828118f8edbfcb42f98f3518dcc46baae85eaa/content
> 12:37:04,061 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.jar" (runtime-name: "test.jar")
> 12:37:04,238 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0003: Processing weld deployment test.jar
> 12:37:04,270 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.3.5.Final
> 12:37:04,319 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-2) WFLYEJB0473: JNDI bindings for session bean named 'LoggingBean' in deployment unit 'deployment "test.jar"' are as follows:
> 	java:global/test/LoggingBean!org.jboss.test.LoggingBean
> 	java:app/test/LoggingBean!org.jboss.test.LoggingBean
> 	java:module/LoggingBean!org.jboss.test.LoggingBean
> 	java:global/test/LoggingBean
> 	java:app/test/LoggingBean
> 	java:module/LoggingBean
> 12:37:04,387 INFO  [stdout] (MSC service thread 1-7) something
> 12:37:04,428 INFO  [org.jboss.weld.Version] (MSC service thread 1-7) WELD-000900: 3.0.2 (Final)
> 12:37:04,544 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Chakra' 8.2.8.Final
> 12:37:04,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."test.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.jar".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1687)
> 	at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.<clinit>(ObserverNotifier.java:480)
> 	at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
> 	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
> 	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> 	at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
> 	at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
> 	at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> 	at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1695)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1674)
> 	... 4 more
> Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
> 	at java.lang.invoke.MethodHandles$Lookup.checkClassAccess(MethodHandles.java:371)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:281)
> 	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:264)
> 	at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:468)
> 	at java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:966)
> 	at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
> 	at java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:856)
> 	... 16 more
> 12:37:04,774 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) WFLYCLINF0002: Started client-mappings cache from ejb container
> 12:37:04,814 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "test.jar"}) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator",
>         "jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"
>     ],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator]",
>         "jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService]",
>         "jboss.deployment.unit.\"test.jar\".deploymentCompleteService is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]",
>         "jboss.deployment.unit.\"test.jar\".moduleDeploymentRuntimeInformationStart is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]"
>     ]
> }
> 12:37:04,815 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "test.jar" was rolled back with the following failure message: 
> {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.jar\".WeldStartService" => "Failed to start service
>     Caused by: java.lang.BootstrapMethodError: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>     Caused by: java.lang.IllegalAccessException: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'"},
>     "WFLYCTL0412: Required services that are not installed:" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator",
>         "jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector"
>     ],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.START is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator]",
>         "jboss.deployment.unit.\"test.jar\".ee.ComponentRegistry is missing [jboss.deployment.unit.\"test.jar\".weld.weldClassIntrospector]",
>         "jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInstantiator is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.WeldInterceptorBindingsService]",
>         "jboss.deployment.unit.\"test.jar\".deploymentCompleteService is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]",
>         "jboss.deployment.unit.\"test.jar\".moduleDeploymentRuntimeInformationStart is missing [jboss.deployment.unit.\"test.jar\".component.LoggingBean.START]"
>     ]
> }
> 12:37:04,830 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0028: Stopped deployment test.jar (runtime-name: test.jar) in 14ms
> {noformat}
> *Expected results:*
> no errors



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Dec 21 06:42:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 21 Dec 2017 06:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2195) CCE when modifying a
 declared type during an incremental update
In-Reply-To: <JIRA.12725829.1513855200000@Atlassian.JIRA>
References: <JIRA.12725829.1513855200000@Atlassian.JIRA>
	<JIRA.12725829.1513855200000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725829.1513855200000.13300.1513856520181@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2195.
---------------------------------
    Resolution: Done


Fixed by https://github.com/kiegroup/drools/commit/d4fad626514d5cfeb54ce071d2bbe1c34148f52a

> CCE when modifying a declared type during an incremental update
> ---------------------------------------------------------------
>
>                 Key: DROOLS-2195
>                 URL: https://issues.jboss.org/browse/DROOLS-2195
>             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 Dec 21 06:59:00 2017
From: issues at jboss.org (=?UTF-8?Q?Mari=C3=A1n_Macik_=28JIRA=29?=)
Date: Thu, 21 Dec 2017 06:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9631) "Failed to reinstate timer"
 warning is shown when creating large number of EJB timers
In-Reply-To: <JIRA.12725827.1513854705000@Atlassian.JIRA>
References: <JIRA.12725827.1513854705000@Atlassian.JIRA>
	<JIRA.12725827.1513854705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725827.1513854705000.13384.1513857540168@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mari?n Macik updated WFLY-9631:
-------------------------------
    Description: 
Hi, [~manovotn],

as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM. Check Environment field for further configuration details.

What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:


{code:java}
WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
    at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
    at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
    at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
    at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
    at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
{code}

The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.

Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.

So I think it has something to do with refresh interval.

Can you please have a look at it?

Thank you very much!

Marian Macik

  was:
Hi, [~manovotn],

as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.

What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:


{code:java}
WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
    at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
    at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
    at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
    at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
    at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
{code}

The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.

Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.

So I think it has something to do with refresh interval.

Can you please have a look at it?

Thank you very much!

Marian Macik



> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-9631
>                 URL: https://issues.jboss.org/browse/WFLY-9631
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27623949f3cafd0e11828bce8a93de21/jboss-eap-7.0/standalone/configuration/standalone-full.xml#L142-L205] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
>            Reporter: Mari?n Macik
>            Assignee: Matej Novotny
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM. Check Environment field for further configuration details.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
>     at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
>     at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
>     at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
>     at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
>     at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it?
> Thank you very much!
> Marian Macik



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Dec 21 07:00:00 2017
From: issues at jboss.org (=?UTF-8?Q?Mari=C3=A1n_Macik_=28JIRA=29?=)
Date: Thu, 21 Dec 2017 07:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9631) "Failed to reinstate timer"
 warning is shown when creating large number of EJB timers
In-Reply-To: <JIRA.12725827.1513854705000@Atlassian.JIRA>
References: <JIRA.12725827.1513854705000@Atlassian.JIRA>
	<JIRA.12725827.1513854705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725827.1513854705000.13387.1513857600224@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mari?n Macik updated WFLY-9631:
-------------------------------
    Description: 
Hi, [~manovotn],

as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM, check Environment field for further configuration details.

What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:


{code:java}
WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
    at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
    at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
    at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
    at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
    at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
{code}

The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.

Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.

So I think it has something to do with refresh interval.

Can you please have a look at it?

Thank you very much!

Marian Macik

  was:
Hi, [~manovotn],

as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM. Check Environment field for further configuration details.

What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:


{code:java}
WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
    at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
    at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
    at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
    at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
    at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
{code}

The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.

Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.

So I think it has something to do with refresh interval.

Can you please have a look at it?

Thank you very much!

Marian Macik



> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-9631
>                 URL: https://issues.jboss.org/browse/WFLY-9631
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27623949f3cafd0e11828bce8a93de21/jboss-eap-7.0/standalone/configuration/standalone-full.xml#L142-L205] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
>            Reporter: Mari?n Macik
>            Assignee: Matej Novotny
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM, check Environment field for further configuration details.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
>     at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
>     at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
>     at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
>     at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
>     at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it?
> Thank you very much!
> Marian Macik



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Dec 21 07:00:00 2017
From: issues at jboss.org (Martin Weiler (JIRA))
Date: Thu, 21 Dec 2017 07:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2196) [GSS](6.4.z) CCE when
 modifying a declared type during an incremental update
In-Reply-To: <JIRA.12725836.1513857562000@Atlassian.JIRA>
References: <JIRA.12725836.1513857562000@Atlassian.JIRA>
	<JIRA.12725836.1513857562442@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725836.1513857562000.13390.1513857600317@Atlassian.JIRA>

Martin Weiler created DROOLS-2196:
-------------------------------------

             Summary: [GSS](6.4.z) CCE when modifying a declared type during an incremental update
                 Key: DROOLS-2196
                 URL: https://issues.jboss.org/browse/DROOLS-2196
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Martin Weiler
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 07:01:01 2017
From: issues at jboss.org (=?UTF-8?Q?Mari=C3=A1n_Macik_=28JIRA=29?=)
Date: Thu, 21 Dec 2017 07:01:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9631) "Failed to reinstate timer"
 warning is shown when creating large number of EJB timers
In-Reply-To: <JIRA.12725827.1513854705000@Atlassian.JIRA>
References: <JIRA.12725827.1513854705000@Atlassian.JIRA>
	<JIRA.12725827.1513854705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725827.1513854705000.13405.1513857661231@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mari?n Macik updated WFLY-9631:
-------------------------------
    Description: 
Hi, [~manovotn],

as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.

What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:


{code:java}
WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
    at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
    at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
    at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
    at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
    at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
{code}

The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.

Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.

So I think it has something to do with refresh interval.

Can you please have a look at it?

Thank you very much!

Marian Macik

For further configuration details, check the Environment field.

  was:
Hi, [~manovotn],

as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM, check Environment field for further configuration details.

What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:


{code:java}
WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
    at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
    at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
    at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
    at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
    at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
{code}

The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.

Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.

So I think it has something to do with refresh interval.

Can you please have a look at it?

Thank you very much!

Marian Macik



> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-9631
>                 URL: https://issues.jboss.org/browse/WFLY-9631
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27623949f3cafd0e11828bce8a93de21/jboss-eap-7.0/standalone/configuration/standalone-full.xml#L142-L205] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
>            Reporter: Mari?n Macik
>            Assignee: Matej Novotny
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
>     at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
>     at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
>     at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
>     at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
>     at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it?
> Thank you very much!
> Marian Macik
> For further configuration details, check the Environment field.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Dec 21 07:02:00 2017
From: issues at jboss.org (=?UTF-8?Q?Mari=C3=A1n_Macik_=28JIRA=29?=)
Date: Thu, 21 Dec 2017 07:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9631) "Failed to reinstate timer"
 warning is shown when creating large number of EJB timers
In-Reply-To: <JIRA.12725827.1513854705000@Atlassian.JIRA>
References: <JIRA.12725827.1513854705000@Atlassian.JIRA>
	<JIRA.12725827.1513854705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725827.1513854705000.13422.1513857720171@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mari?n Macik updated WFLY-9631:
-------------------------------
    Description: 
Hi, [~manovotn],

as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.

What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:


{code:java}
WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
    at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
    at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
    at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
    at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
    at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
{code}

The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.

Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.

So I think it has something to do with refresh interval.

Can you please have a look at it? For further configuration details, check the Environment field.

Thank you very much!

Marian Macik


  was:
Hi, [~manovotn],

as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.

What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:


{code:java}
WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
    at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
    at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
    at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
    at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
    at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
{code}

The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.

Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.

So I think it has something to do with refresh interval.

Can you please have a look at it?

Thank you very much!

Marian Macik

For further configuration details, check the Environment field.



> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-9631
>                 URL: https://issues.jboss.org/browse/WFLY-9631
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27623949f3cafd0e11828bce8a93de21/jboss-eap-7.0/standalone/configuration/standalone-full.xml#L142-L205] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
>            Reporter: Mari?n Macik
>            Assignee: Matej Novotny
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
>     at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
>     at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
>     at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
>     at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
>     at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it? For further configuration details, check the Environment field.
> Thank you very much!
> Marian Macik



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Dec 21 07:56:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 21 Dec 2017 07:56:00 -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.1513860905081@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725844.1513860905000.13574.1513860960388@Atlassian.JIRA>

Darran Lofthouse created ELY-1471:
-------------------------------------

             Summary: 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.Beta12


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 Dec 21 07:59:00 2017
From: issues at jboss.org (Martin Stefanko (JIRA))
Date: Thu, 21 Dec 2017 07:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3282) Duplicate record is written
 in property file when group name set to empty
In-Reply-To: <JIRA.12711353.1505217486000@Atlassian.JIRA>
References: <JIRA.12711353.1505217486000@Atlassian.JIRA>
	<JIRA.12711353.1505217486000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12711353.1505217486000.13594.1513861140298@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Stefanko updated WFCORE-3282:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2832, https://github.com/wildfly/wildfly-core/pull/3009  (was: https://github.com/wildfly/wildfly-core/pull/2832)


> Duplicate record is written in property file when group name set to empty
> -------------------------------------------------------------------------
>
>                 Key: WFCORE-3282
>                 URL: https://issues.jboss.org/browse/WFCORE-3282
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 3.0.2.CR1
>            Reporter: Martin Stefanko
>            Assignee: Martin Stefanko
>
> Duplicate records are registered in mgmt-groups.properties and application-roles.properties if adding user with empty group name as follows.
> 1. Add user "testuser1" with empty group from add-user.sh.
> $JBOSS_HOME/bin/add-user.sh -sc ./standalone/configuration -u testuser1 -p RedHat1! -g ""
> 2. After that, the following record is written in the group property file.
> - mgmt-groups.properties (application-roles.properties)
> testuser1=
> 3. Add user "testuser2" with empty group from add-user.sh.
> $JBOSS_HOME/bin/add-user.sh -sc ./standalone/configuration -u testuser2 -p RedHat1! -g ""
> 4. After that, the user records that have empty group will be registered duplicately as below.
> - mgmt-groups.properties (application-roles.properties)
> testuser1=
> testuser2=
> testuser1=    # duplicate record



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 08:12:00 2017
From: issues at jboss.org (Martin Mazanek (JIRA))
Date: Thu, 21 Dec 2017 08:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-818) Add ability to dynamically
 select a keystore or credential alias based on the authentication being
 performed
In-Reply-To: <JIRA.12665707.1481045150000@Atlassian.JIRA>
References: <JIRA.12665707.1481045150000@Atlassian.JIRA>
	<JIRA.12665707.1481045150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665707.1481045150000.13622.1513861920105@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Mazanek reassigned ELY-818:
----------------------------------

    Assignee: Martin Mazanek


> Add ability to dynamically select a keystore or credential alias based on the authentication being performed
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-818
>                 URL: https://issues.jboss.org/browse/ELY-818
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client, XML
>            Reporter: David Lloyd
>            Assignee: Martin Mazanek
>
> In the configuration of the auth client, it should be possible to specify that the alias of the certificate/key/other credentials (to use in a key store or credential store) should be derived from the authentication principal, either exactly (via getName()) or via a Principal transformation of some kind, or alternatively from the target host name (also via optional name rewriting).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 09:13:00 2017
From: issues at jboss.org (Guillaume Smet (JIRA))
Date: Thu, 21 Dec 2017 09:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9615) Upgrade to Bean Validation
 2.0 and Hibernate Validator 6.0
In-Reply-To: <JIRA.12724925.1513258949000@Atlassian.JIRA>
References: <JIRA.12724925.1513258949000@Atlassian.JIRA>
	<JIRA.12724925.1513258949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724925.1513258949000.13849.1513865580444@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Smet updated WFLY-9615:
---------------------------------
    Summary: Upgrade to Bean Validation 2.0 and Hibernate Validator 6.0  (was: Upgrade Hibernate Validator to 6.0.6.Final)


> Upgrade to Bean Validation 2.0 and Hibernate Validator 6.0
> ----------------------------------------------------------
>
>                 Key: WFLY-9615
>                 URL: https://issues.jboss.org/browse/WFLY-9615
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Guillaume Smet
>            Assignee: Jason Greene
>
> We would like to upgrade Hibernate Validator to 6.0.6.Final in WildFly 12.
> Here is our migration guide:
> https://developer.jboss.org/wiki/HibernateValidatorMigrationGuide#jive_content_id_60x
> You'll notice that in 6.0.6, we have reintroduced a few APIs that we had removed in the previous versions of 6 for this WF upgrade: we had them deprecated in 5.4 then removed in 6 but as WF is still using 5.3, WF users didn't have any notice of that. That's why we decided to reintroduce them before proposing an upgrade in WildFly.
> The other APIs removed were marked as experimental and have been superseded by standard features in Bean Validation 2.0 (which is part of Java EE 8).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 09:14:00 2017
From: issues at jboss.org (Guillaume Smet (JIRA))
Date: Thu, 21 Dec 2017 09:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9615) Upgrade to Bean Validation
 2.0 and Hibernate Validator 6.0
In-Reply-To: <JIRA.12724925.1513258949000@Atlassian.JIRA>
References: <JIRA.12724925.1513258949000@Atlassian.JIRA>
	<JIRA.12724925.1513258949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724925.1513258949000.13851.1513865640325@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Smet updated WFLY-9615:
---------------------------------
    Description: 
We would like to upgrade Hibernate Validator to 6.0.7.Final in WildFly 12.

Here is our migration guide:
https://developer.jboss.org/wiki/HibernateValidatorMigrationGuide#jive_content_id_60x

You'll notice that in 6.0.6, we have reintroduced a few APIs that we had removed in the previous versions of 6 for this WF upgrade: we had them deprecated in 5.4 then removed in 6 but as WF is still using 5.3, WF users didn't have any notice of that. That's why we decided to reintroduce them before proposing an upgrade in WildFly.

The other APIs removed were marked as experimental and have been superseded by standard features in Bean Validation 2.0 (which is part of Java EE 8).

  was:
We would like to upgrade Hibernate Validator to 6.0.6.Final in WildFly 12.

Here is our migration guide:
https://developer.jboss.org/wiki/HibernateValidatorMigrationGuide#jive_content_id_60x

You'll notice that in 6.0.6, we have reintroduced a few APIs that we had removed in the previous versions of 6 for this WF upgrade: we had them deprecated in 5.4 then removed in 6 but as WF is still using 5.3, WF users didn't have any notice of that. That's why we decided to reintroduce them before proposing an upgrade in WildFly.

The other APIs removed were marked as experimental and have been superseded by standard features in Bean Validation 2.0 (which is part of Java EE 8).



> Upgrade to Bean Validation 2.0 and Hibernate Validator 6.0
> ----------------------------------------------------------
>
>                 Key: WFLY-9615
>                 URL: https://issues.jboss.org/browse/WFLY-9615
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Guillaume Smet
>            Assignee: Jason Greene
>
> We would like to upgrade Hibernate Validator to 6.0.7.Final in WildFly 12.
> Here is our migration guide:
> https://developer.jboss.org/wiki/HibernateValidatorMigrationGuide#jive_content_id_60x
> You'll notice that in 6.0.6, we have reintroduced a few APIs that we had removed in the previous versions of 6 for this WF upgrade: we had them deprecated in 5.4 then removed in 6 but as WF is still using 5.3, WF users didn't have any notice of that. That's why we decided to reintroduce them before proposing an upgrade in WildFly.
> The other APIs removed were marked as experimental and have been superseded by standard features in Bean Validation 2.0 (which is part of Java EE 8).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 09:14:00 2017
From: issues at jboss.org (Guillaume Smet (JIRA))
Date: Thu, 21 Dec 2017 09:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9615) Upgrade to Bean Validation
 2.0 and Hibernate Validator 6.0
In-Reply-To: <JIRA.12724925.1513258949000@Atlassian.JIRA>
References: <JIRA.12724925.1513258949000@Atlassian.JIRA>
	<JIRA.12724925.1513258949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724925.1513258949000.13855.1513865640474@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507857#comment-13507857 ] 

Guillaume Smet commented on WFLY-9615:
--------------------------------------

Pull request: https://github.com/wildfly/wildfly/pull/10725 .

> Upgrade to Bean Validation 2.0 and Hibernate Validator 6.0
> ----------------------------------------------------------
>
>                 Key: WFLY-9615
>                 URL: https://issues.jboss.org/browse/WFLY-9615
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Guillaume Smet
>            Assignee: Jason Greene
>
> We would like to upgrade Hibernate Validator to 6.0.7.Final in WildFly 12.
> Here is our migration guide:
> https://developer.jboss.org/wiki/HibernateValidatorMigrationGuide#jive_content_id_60x
> You'll notice that in 6.0.6, we have reintroduced a few APIs that we had removed in the previous versions of 6 for this WF upgrade: we had them deprecated in 5.4 then removed in 6 but as WF is still using 5.3, WF users didn't have any notice of that. That's why we decided to reintroduce them before proposing an upgrade in WildFly.
> The other APIs removed were marked as experimental and have been superseded by standard features in Bean Validation 2.0 (which is part of Java EE 8).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 09:26:00 2017
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Thu, 21 Dec 2017 09:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9631) "Failed to reinstate timer"
 warning is shown when creating large number of EJB timers
In-Reply-To: <JIRA.12725827.1513854705000@Atlassian.JIRA>
References: <JIRA.12725827.1513854705000@Atlassian.JIRA>
	<JIRA.12725827.1513854705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725827.1513854705000.13895.1513866360589@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507861#comment-13507861 ] 

Matej Novotny commented on WFLY-9631:
-------------------------------------

Marian also mentioned that those two EAP servers *are not* clustered. They only share the underlying DB for timers.

> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-9631
>                 URL: https://issues.jboss.org/browse/WFLY-9631
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27623949f3cafd0e11828bce8a93de21/jboss-eap-7.0/standalone/configuration/standalone-full.xml#L142-L205] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
>            Reporter: Mari?n Macik
>            Assignee: Matej Novotny
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN  [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
>     at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
>     at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
>     at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
>     at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
>     at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
>     at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it? For further configuration details, check the Environment field.
> Thank you very much!
> Marian Macik



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Dec 21 10:11:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 21 Dec 2017 10:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869010000@Atlassian.JIRA>
References: <JIRA.12725867.1513869010000@Atlassian.JIRA>
	<JIRA.12725867.1513869010669@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869010000.14030.1513869060224@Atlassian.JIRA>

Jan Kalina created ELY-1472:
-------------------------------

             Summary: [native kerberos] setting channelBinding of gssContext when not used
                 Key: ELY-1472
                 URL: https://issues.jboss.org/browse/ELY-1472
             Project: WildFly Elytron
          Issue Type: Bug
          Components: SASL
    Affects Versions: 1.2.0.Beta11
            Reporter: Jan Kalina
            Assignee: Jan Kalina


gssContext's channelBinding is set even when channel binding is not used.

This lead to following error when using native Kerberos library:

{code}
[GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
[GSSLibStub_acceptContext] before3: inToken.length=515
[GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
[GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
[GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
c/r/s = 0/4/0
{code}

Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.

This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 10:11:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 21 Dec 2017 10:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869011000@Atlassian.JIRA>
References: <JIRA.12725867.1513869011000@Atlassian.JIRA>
	<JIRA.12725867.1513869011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869011000.14032.1513869060272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1472:
----------------------------
    Labels: kerberos native  (was: )


> [native kerberos] setting channelBinding of gssContext when not used
> --------------------------------------------------------------------
>
>                 Key: ELY-1472
>                 URL: https://issues.jboss.org/browse/ELY-1472
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: kerberos
>
> gssContext's channelBinding is set even when channel binding is not used.
> This lead to following error when using native Kerberos library:
> {code}
> [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
> [GSSLibStub_acceptContext] before3: inToken.length=515
> [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
> [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
> [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
> c/r/s = 0/4/0
> {code}
> Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.
> This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 10:11:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 21 Dec 2017 10:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869011000@Atlassian.JIRA>
References: <JIRA.12725867.1513869011000@Atlassian.JIRA>
	<JIRA.12725867.1513869011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869011000.14034.1513869060316@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1472:
----------------------------
    Labels: kerberos  (was: kerberos native)


> [native kerberos] setting channelBinding of gssContext when not used
> --------------------------------------------------------------------
>
>                 Key: ELY-1472
>                 URL: https://issues.jboss.org/browse/ELY-1472
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: kerberos
>
> gssContext's channelBinding is set even when channel binding is not used.
> This lead to following error when using native Kerberos library:
> {code}
> [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
> [GSSLibStub_acceptContext] before3: inToken.length=515
> [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
> [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
> [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
> c/r/s = 0/4/0
> {code}
> Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.
> This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 10:28:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 21 Dec 2017 10:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869011000@Atlassian.JIRA>
References: <JIRA.12725867.1513869011000@Atlassian.JIRA>
	<JIRA.12725867.1513869011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869011000.14089.1513870080175@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1472:
----------------------------
    Description: 
Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used.

This lead to following error when using native Kerberos library:

{code}
[GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
[GSSLibStub_acceptContext] before3: inToken.length=515
[GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
[GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
[GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
c/r/s = 0/4/0
{code}

Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.

This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.

  was:
gssContext's channelBinding is set even when channel binding is not used.

This lead to following error when using native Kerberos library:

{code}
[GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
[GSSLibStub_acceptContext] before3: inToken.length=515
[GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
[GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
[GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
c/r/s = 0/4/0
{code}

Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.

This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



> [native kerberos] setting channelBinding of gssContext when not used
> --------------------------------------------------------------------
>
>                 Key: ELY-1472
>                 URL: https://issues.jboss.org/browse/ELY-1472
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: kerberos
>
> Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used.
> This lead to following error when using native Kerberos library:
> {code}
> [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
> [GSSLibStub_acceptContext] before3: inToken.length=515
> [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
> [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
> [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
> c/r/s = 0/4/0
> {code}
> Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.
> This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 10:34:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 21 Dec 2017 10:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869011000@Atlassian.JIRA>
References: <JIRA.12725867.1513869011000@Atlassian.JIRA>
	<JIRA.12725867.1513869011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869011000.14107.1513870440084@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507889#comment-13507889 ] 

Jan Kalina commented on ELY-1472:
---------------------------------

If the setChannelBinding really should not be used, maybe this can resolve also ELY-1331 ...

> [native kerberos] setting channelBinding of gssContext when not used
> --------------------------------------------------------------------
>
>                 Key: ELY-1472
>                 URL: https://issues.jboss.org/browse/ELY-1472
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: kerberos
>
> Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used.
> This lead to following error when using native Kerberos library:
> {code}
> [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
> [GSSLibStub_acceptContext] before3: inToken.length=515
> [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
> [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
> [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
> c/r/s = 0/4/0
> {code}
> Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.
> This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 12:43:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 21 Dec 2017 12:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869011000@Atlassian.JIRA>
References: <JIRA.12725867.1513869011000@Atlassian.JIRA>
	<JIRA.12725867.1513869011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869011000.14345.1513878180059@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1472:
----------------------------
    Comment: was deleted

(was: If the setChannelBinding really should not be used, maybe this can resolve also ELY-1331 ...)


> [native kerberos] setting channelBinding of gssContext when not used
> --------------------------------------------------------------------
>
>                 Key: ELY-1472
>                 URL: https://issues.jboss.org/browse/ELY-1472
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: kerberos
>
> Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used.
> This lead to following error when using native Kerberos library:
> {code}
> [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
> [GSSLibStub_acceptContext] before3: inToken.length=515
> [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
> [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
> [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
> c/r/s = 0/4/0
> {code}
> Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.
> This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 12:47:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 21 Dec 2017 12:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869011000@Atlassian.JIRA>
References: <JIRA.12725867.1513869011000@Atlassian.JIRA>
	<JIRA.12725867.1513869011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869011000.14356.1513878420060@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507923#comment-13507923 ] 

Jan Kalina commented on ELY-1472:
---------------------------------

Edit: by RFC the GSS-CHANNEL-BINDINGS Structure must be used even when negotiated application level channel binding is unsupported (gs2-cb-flag=n) - need to investigate more...

> [native kerberos] setting channelBinding of gssContext when not used
> --------------------------------------------------------------------
>
>                 Key: ELY-1472
>                 URL: https://issues.jboss.org/browse/ELY-1472
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: kerberos
>
> Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used.
> This lead to following error when using native Kerberos library:
> {code}
> [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
> [GSSLibStub_acceptContext] before3: inToken.length=515
> [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
> [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
> [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
> c/r/s = 0/4/0
> {code}
> Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.
> This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 13:20:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 21 Dec 2017 13:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869011000@Atlassian.JIRA>
References: <JIRA.12725867.1513869011000@Atlassian.JIRA>
	<JIRA.12725867.1513869011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869011000.14424.1513880400057@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507931#comment-13507931 ] 

Jan Kalina commented on ELY-1472:
---------------------------------

Look like {{cb->initiator_address.length}} is not initialized in {{GSSLibStub.c}} in OpenJDK:
{code}
cb->initiator_address.length = 140608975239744 (should be 0?)
cb->acceptor_address.length = 0
{code}

> [native kerberos] setting channelBinding of gssContext when not used
> --------------------------------------------------------------------
>
>                 Key: ELY-1472
>                 URL: https://issues.jboss.org/browse/ELY-1472
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: kerberos
>
> Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used.
> This lead to following error when using native Kerberos library:
> {code}
> [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
> [GSSLibStub_acceptContext] before3: inToken.length=515
> [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
> [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
> [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
> c/r/s = 0/4/0
> {code}
> Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.
> This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 13:21:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 21 Dec 2017 13:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869011000@Atlassian.JIRA>
References: <JIRA.12725867.1513869011000@Atlassian.JIRA>
	<JIRA.12725867.1513869011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869011000.14426.1513880460122@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507931#comment-13507931 ] 

Jan Kalina edited comment on ELY-1472 at 12/21/17 1:20 PM:
-----------------------------------------------------------

Look like {{cb->initiator_address.length}} is not initialized in {{GSSLibStub.c}} in OpenJDK:
{code}
cb->initiator_address.length = 140608975239744 (should be 0?)
cb->acceptor_address.length = 0
{code}
=> wrong channel binding checksum in kg_checksum_channel_bindings in util_cksum.c in krb5


was (Author: honza889):
Look like {{cb->initiator_address.length}} is not initialized in {{GSSLibStub.c}} in OpenJDK:
{code}
cb->initiator_address.length = 140608975239744 (should be 0?)
cb->acceptor_address.length = 0
{code}

> [native kerberos] setting channelBinding of gssContext when not used
> --------------------------------------------------------------------
>
>                 Key: ELY-1472
>                 URL: https://issues.jboss.org/browse/ELY-1472
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: kerberos
>
> Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used.
> This lead to following error when using native Kerberos library:
> {code}
> [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
> [GSSLibStub_acceptContext] before3: inToken.length=515
> [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
> [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
> [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
> c/r/s = 0/4/0
> {code}
> Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.
> This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 14:16:00 2017
From: issues at jboss.org (Serg Pol (JIRA))
Date: Thu, 21 Dec 2017 14:16: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.14646.1513883760791@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507958#comment-13507958 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

Thank You very much. (y)
Marry Christmas and Happy New Year!
p.s. i had impression in this case that the number of batch jobs that run in the same time was less as configured max number(10) 

> 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  Thu Dec 21 15:39:00 2017
From: issues at jboss.org (andrea tarocchi (JIRA))
Date: Thu, 21 Dec 2017 15:39: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.1513888720034@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725932.1513888720000.14731.1513888740157@Atlassian.JIRA>

andrea tarocchi created JGRP-2243:
-------------------------------------

             Summary: 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






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:32:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 21 Dec 2017 16:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3478) Tighten visibility on some
 AttributeDefinition fields
In-Reply-To: <JIRA.12725934.1513891890000@Atlassian.JIRA>
References: <JIRA.12725934.1513891890000@Atlassian.JIRA>
	<JIRA.12725934.1513891890156@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725934.1513891890000.14766.1513891920125@Atlassian.JIRA>

Brian Stansberry created WFCORE-3478:
----------------------------------------

             Summary: Tighten visibility on some AttributeDefinition fields
                 Key: WFCORE-3478
                 URL: https://issues.jboss.org/browse/WFCORE-3478
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


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  Thu Dec 21 16:33:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 21 Dec 2017 16:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3478) Tighten visibility on some
 AttributeDefinition and AbstractAttributeDefinitionBuilder fields
In-Reply-To: <JIRA.12725934.1513891890000@Atlassian.JIRA>
References: <JIRA.12725934.1513891890000@Atlassian.JIRA>
	<JIRA.12725934.1513891890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725934.1513891890000.14770.1513891980457@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3478:
-------------------------------------
    Summary: Tighten visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields  (was: Tighten visibility on some AttributeDefinition fields)


> Tighten visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3478
>                 URL: https://issues.jboss.org/browse/WFCORE-3478
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> 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  Thu Dec 21 16:34:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 21 Dec 2017 16:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3478) Tighten visibility on some
 AttributeDefinition and AbstractAttributeDefinitionBuilder fields
In-Reply-To: <JIRA.12725934.1513891890000@Atlassian.JIRA>
References: <JIRA.12725934.1513891890000@Atlassian.JIRA>
	<JIRA.12725934.1513891890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725934.1513891890000.14772.1513892040156@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3478:
-------------------------------------
    Description: AttributeDefinition and AbstractAttributeDefinitionBuilder in the controller module have some fields that are protected. This will make it problematic to evolve the management code in the future. Remove all direct use of these, switching to getters instead.  (was: 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.)


> Tighten visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3478
>                 URL: https://issues.jboss.org/browse/WFCORE-3478
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> AttributeDefinition and AbstractAttributeDefinitionBuilder in the controller module have some fields that are protected. This will make it problematic to evolve the management code in the future. Remove all direct use of these, switching to getters instead.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:34:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 21 Dec 2017 16:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3478) Tighten visibility on some
 AttributeDefinition and AbstractAttributeDefinitionBuilder fields
In-Reply-To: <JIRA.12725934.1513891890000@Atlassian.JIRA>
References: <JIRA.12725934.1513891890000@Atlassian.JIRA>
	<JIRA.12725934.1513891890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725934.1513891890000.14774.1513892040411@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3478:
-------------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly-core/pull/3006)


> Tighten visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3478
>                 URL: https://issues.jboss.org/browse/WFCORE-3478
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> AttributeDefinition and AbstractAttributeDefinitionBuilder in the controller module have some fields that are protected. This will make it problematic to evolve the management code in the future. Remove all direct use of these, switching to getters instead.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:34:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 21 Dec 2017 16:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9632) Tighten visibility on some
 AttributeDefinition and AbstractAttributeDefinitionBuilder fields
In-Reply-To: <JIRA.12725934.1513891890000@Atlassian.JIRA>
References: <JIRA.12725934.1513891890000@Atlassian.JIRA>
	<JIRA.12725934.1513891890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725934.1513891890000.14776.1513892040595@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFCORE-3478 to WFLY-9632:
------------------------------------------------

        Project: WildFly  (was: WildFly Core)
            Key: WFLY-9632  (was: WFCORE-3478)
    Component/s: Domain Management
                     (was: Domain Management)


> Tighten visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9632
>                 URL: https://issues.jboss.org/browse/WFLY-9632
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> AttributeDefinition and AbstractAttributeDefinitionBuilder in the controller module have some fields that are protected. This will make it problematic to evolve the management code in the future. Remove all direct use of these, switching to getters instead.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:35:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 21 Dec 2017 16:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9632) Prep for tightened visibility
 on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields
In-Reply-To: <JIRA.12725934.1513891890000@Atlassian.JIRA>
References: <JIRA.12725934.1513891890000@Atlassian.JIRA>
	<JIRA.12725934.1513891890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725934.1513891890000.14778.1513892100166@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-9632:
-----------------------------------
    Summary: Prep for tightened visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields  (was: Tighten visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields)


> Prep for tightened visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9632
>                 URL: https://issues.jboss.org/browse/WFLY-9632
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> AttributeDefinition and AbstractAttributeDefinitionBuilder in the controller module have some fields that are protected. This will make it problematic to evolve the management code in the future. Remove all direct use of these, switching to getters instead.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:41:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 16:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3479) Deploying an empty
 deployment and adding content later fails in a composite
In-Reply-To: <JIRA.12725935.1513892444000@Atlassian.JIRA>
References: <JIRA.12725935.1513892444000@Atlassian.JIRA>
	<JIRA.12725935.1513892444246@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725935.1513892444000.14791.1513892460166@Atlassian.JIRA>

Kabir Khan created WFCORE-3479:
----------------------------------

             Summary: Deploying an empty deployment and adding content later fails in a composite
                 Key: WFCORE-3479
                 URL: https://issues.jboss.org/browse/WFCORE-3479
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 3.0.10.Final
            Reporter: Kabir Khan
            Assignee: Brian Stansberry






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:44:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 16:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9633) Add mixed domain tests for
	EAP 7.1.0
In-Reply-To: <JIRA.12725936.1513892580000@Atlassian.JIRA>
References: <JIRA.12725936.1513892580000@Atlassian.JIRA>
	<JIRA.12725936.1513892580989@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725936.1513892580000.14795.1513892640213@Atlassian.JIRA>

Kabir Khan created WFLY-9633:
--------------------------------

             Summary: 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: Brian Stansberry






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:44:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 21 Dec 2017 16:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3458) External CS,
 PKCS11 can't be configured with externalPath
In-Reply-To: <JIRA.12724714.1513181174000@Atlassian.JIRA>
References: <JIRA.12724714.1513181174000@Atlassian.JIRA>
	<JIRA.12724714.1513181174000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724714.1513181174000.14801.1513892640366@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505087#comment-13505087 ] 

Ilia Vassilev edited comment on WFCORE-3458 at 12/21/17 4:43 PM:
-----------------------------------------------------------------

In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"

When location is not set for most common filebased keystore types (JKS,
JCEKS and PKCS12), Elytron will throw exception.



was (Author: ivassile):
In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"


> External CS, PKCS11 can't be configured with externalPath 
> ----------------------------------------------------------
>
>                 Key: WFCORE-3458
>                 URL: https://issues.jboss.org/browse/WFCORE-3458
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 4.0.0.Alpha4
>            Reporter: Ilia Vassilev
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 	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.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> 	at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> 	... 5 more
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 	at java.nio.file.Files.newByteChannel(Files.java:361)
> 	at java.nio.file.Files.newByteChannel(Files.java:407)
> 	at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> 	at java.nio.file.Files.newInputStream(Files.java:152)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> 	... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
>     Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
>     Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
>     private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
>         KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
>         keyStore = getKeyStoreInstance("JCEKS");
>         externalStorage = new ExternalStorage();
>         try {
>             final char[] storePassword = getStorePassword(protectionParameter);
>             if (keyContainingKeyStoreLocation != null) {
>                 try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
>                     keyContainingKeyStore.load(is, storePassword);
>                 }
>             } else {
>                 // keystore without file (e.g. PKCS11)
>                 synchronized (EmptyProvider.getInstance()) {
>                     keyContainingKeyStore.load(null, storePassword);
>                 }
>             }
>             externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
>         } catch(IOException | GeneralSecurityException e) {
>             throw log.cannotInitializeCredentialStore(e);
>         }
>     }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:45:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 21 Dec 2017 16:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3458) External CS,
 PKCS11 can't be configured with externalPath
In-Reply-To: <JIRA.12724714.1513181174000@Atlassian.JIRA>
References: <JIRA.12724714.1513181174000@Atlassian.JIRA>
	<JIRA.12724714.1513181174000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724714.1513181174000.14807.1513892700403@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505087#comment-13505087 ] 

Ilia Vassilev edited comment on WFCORE-3458 at 12/21/17 4:44 PM:
-----------------------------------------------------------------

In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"

When location is not set for most common filebased keystore types (JKS, JCEKS and PKCS12), Elytron will throw exception.



was (Author: ivassile):
In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"

When location is not set for most common filebased keystore types (JKS,
JCEKS and PKCS12), Elytron will throw exception.


> External CS, PKCS11 can't be configured with externalPath 
> ----------------------------------------------------------
>
>                 Key: WFCORE-3458
>                 URL: https://issues.jboss.org/browse/WFCORE-3458
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 4.0.0.Alpha4
>            Reporter: Ilia Vassilev
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 	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.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> 	at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> 	at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> 	... 5 more
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 	at java.nio.file.Files.newByteChannel(Files.java:361)
> 	at java.nio.file.Files.newByteChannel(Files.java:407)
> 	at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> 	at java.nio.file.Files.newInputStream(Files.java:152)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> 	... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
>     Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
>     Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
>     private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
>         KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
>         keyStore = getKeyStoreInstance("JCEKS");
>         externalStorage = new ExternalStorage();
>         try {
>             final char[] storePassword = getStorePassword(protectionParameter);
>             if (keyContainingKeyStoreLocation != null) {
>                 try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
>                     keyContainingKeyStore.load(is, storePassword);
>                 }
>             } else {
>                 // keystore without file (e.g. PKCS11)
>                 synchronized (EmptyProvider.getInstance()) {
>                     keyContainingKeyStore.load(null, storePassword);
>                 }
>             }
>             externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
>         } catch(IOException | GeneralSecurityException e) {
>             throw log.cannotInitializeCredentialStore(e);
>         }
>     }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:45:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 16:45: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.1513892690308@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725937.1513892690000.14818.1513892700730@Atlassian.JIRA>

Kabir Khan created WFLY-9634:
--------------------------------

             Summary: 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: Brian Stansberry
             Fix For: 12.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:47:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 16:47: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.14822.1513892820149@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-9634:
-----------------------------
    Description: 
I have added an
{code}
        // TODO WFLY-9634
        Assume.assumeFalse(supportManagedExplodedDeployment());
{code}
to disable this test for 7.1.0


> 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: Brian Stansberry
>             Fix For: 12.0.0.Alpha1
>
>
> I have added an
> {code}
>         // TODO WFLY-9634
>         Assume.assumeFalse(supportManagedExplodedDeployment());
> {code}
> to disable this test for 7.1.0



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:48:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 21 Dec 2017 16:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9428) Distributed shared web
 sessions can passivate prematurely
In-Reply-To: <JIRA.12715442.1507627044000@Atlassian.JIRA>
References: <JIRA.12715442.1507627044000@Atlassian.JIRA>
	<JIRA.12715442.1507627044000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12715442.1507627044000.14827.1513892880188@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-9428:
-------------------------------
    Summary: Distributed shared web sessions can passivate prematurely  (was: Distributed shared web sessions can expire prematurely)


> Distributed shared web sessions can passivate prematurely
> ---------------------------------------------------------
>
>                 Key: WFLY-9428
>                 URL: https://issues.jboss.org/browse/WFLY-9428
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final, 11.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance.  However, each deployment will use a separate session manager instance (created from the shared factory).  Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus expire prematurely.
> To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:52:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 21 Dec 2017 16:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9428) Distributed shared web
 sessions can passivate prematurely
In-Reply-To: <JIRA.12715442.1507627044000@Atlassian.JIRA>
References: <JIRA.12715442.1507627044000@Atlassian.JIRA>
	<JIRA.12715442.1507627044000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12715442.1507627044000.14832.1513893120304@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-9428:
-------------------------------
    Description: 
When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance.  However, each deployment will use a separate session manager instance (created from the shared factory).  Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus attempt to expire prematurely, thus failing to expire when it should.

To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().

  was:
When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance.  However, each deployment will use a separate session manager instance (created from the shared factory).  Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus expire prematurely.

To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().



> Distributed shared web sessions can passivate prematurely
> ---------------------------------------------------------
>
>                 Key: WFLY-9428
>                 URL: https://issues.jboss.org/browse/WFLY-9428
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final, 11.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance.  However, each deployment will use a separate session manager instance (created from the shared factory).  Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus attempt to expire prematurely, thus failing to expire when it should.
> To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 16:57:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 21 Dec 2017 16:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9428) Distributed shared web
 sessions can passivate prematurely
In-Reply-To: <JIRA.12715442.1507627044000@Atlassian.JIRA>
References: <JIRA.12715442.1507627044000@Atlassian.JIRA>
	<JIRA.12715442.1507627044000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12715442.1507627044000.14844.1513893420236@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-9428:
-------------------------------
    Priority: Major  (was: Critical)


> Distributed shared web sessions can passivate prematurely
> ---------------------------------------------------------
>
>                 Key: WFLY-9428
>                 URL: https://issues.jboss.org/browse/WFLY-9428
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final, 11.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance.  However, each deployment will use a separate session manager instance (created from the shared factory).  Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus attempt to expire prematurely, thus failing to expire when it should.
> To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 17:01:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 17:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3479) Deploying an empty
 deployment and adding content later fails in a composite
In-Reply-To: <JIRA.12725935.1513892444000@Atlassian.JIRA>
References: <JIRA.12725935.1513892444000@Atlassian.JIRA>
	<JIRA.12725935.1513892444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725935.1513892444000.14852.1513893660416@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-3479:
-------------------------------
    Description: 
When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following:

{code}
1) Create an empty deployment
2) Add some content to the deployment using input streams
3) Add the deployment to a server group
{code}
However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem. 

Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC:
{code}
{
    "operation" => "composite",
    "address" => [],
    "steps" => [
        {
            "operation" => "add",
            "address" => [("deployment" => "test.war")],
            "content" => [{"empty" => true}]
        },
        {
            "operation" => "add-content",
            "address" => [("deployment" => "test.war")],
            "content" => [
                {
                    "target-path" => "index.html",
                    "input-stream-index" => 0
                },
                {
                    "target-path" => "index2.html",
                    "input-stream-index" => 1
                }
            ]
        },
        {
            "operation" => "add",
            "address" => [
                ("server-group" => "other-server-group"),
                ("deployment" => "test.war")
            ],
            "enabled" => true
        },
        {
            "operation" => "add",
            "address" => [
                ("server-group" => "main-server-group"),
                ("deployment" => "test.war")
            ],
            "enabled" => true
        }
    ],
    "operation-headers" => {
        "caller-type" => "user",
        "access-mechanism" => "NATIVE",
        "domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745",
        "execute-for-coordinator" => true
    }
}

{code}

What ends up being pushed to the slave is:
{code}
{

    "operation" => "composite",
    "address" => [],
    "steps" => [
        {
            "operation" => "add",
            "address" => [("deployment" => "test.war")],
            "content" => [{
                "hash" => bytes {
                    0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16,
                    0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29,
                    0x04, 0x05, 0x9d, 0x82
                },
                "archive" => false
            }],
            "operation-headers" => {
                "caller-type" => "user",
                "access-mechanism" => "NATIVE",
                "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
            },
            "runtime-name" => undefined
        },
        {
            "operation" => "add-content",
            "address" => [("deployment" => "test.war")],
            "content" => [{
                "hash" => bytes {
                    0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
                    0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
                    0x78, 0x59, 0x91, 0x63
                },
                "target-path" => "."
            }],
            "operation-headers" => {
                "caller-type" => "user",
                "access-mechanism" => "NATIVE",
                "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
            },
            "path" => [
                "index.html",
                "index2.html"
            ]
        },
        {
            "operation" => "add",
            "address" => [
                ("server-group" => "other-server-group"),
                ("deployment" => "test.war")
            ],
            "enabled" => true
        },
        {
            "operation" => "add",
            "address" => [
                ("server-group" => "main-server-group"),
                ("deployment" => "test.war")
            ],
            "enabled" => true
        }
    ],
    "operation-headers" => {
        "caller-type" => "user",
        "access-mechanism" => "NATIVE",
        "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc",
        "execute-for-coordinator" => true
    }
}

{code}

The error reported by the DC is:
{code}
{
    "outcome" => "failed",
    "result" => {
        "step-1" => {
            "outcome" => "failed",
            "rolled-back" => true
        },
        "step-2" => {
            "outcome" => "failed",
            "rolled-back" => true
        },
        "step-3" => {
            "outcome" => "failed",
            "rolled-back" => true
        },
        "step-4" => {
            "outcome" => "failed",
            "rolled-back" => true
        }
    },
    "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}},
    "rolled-back" => true,
    "server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => {
        "outcome" => "failed",
        "result" => {
            "step-1" => {
                "outcome" => "failed",
                "failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found",
                "rolled-back" => true
            },
            "step-2" => {"outcome" => undefined}
        },
        "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}},
        "rolled-back" => true
    }}}}}}
}
{code}

Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC:
{code}
{
    "operation" => "composite",
    "steps" => [
        {
            "operation" => "add-content",
            "address" => [("deployment" => "test.war")],
            "content" => [{
                "hash" => bytes {
                    0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
                    0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
                    0x78, 0x59, 0x91, 0x63
                },
                "target-path" => "."
            }],
            "operation-headers" => {
                "access-mechanism" => "NATIVE",
                "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
            },
            "path" => [
                "index.html",
                "index2.html"
            ]
        },
        {
            "operation" => "add",
            "address" => [("deployment" => "test.war")],
            "enabled" => true,
            "operation-headers" => {
                "access-mechanism" => "NATIVE",
                "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
            },
            "runtime-name" => "test.war",
            "content" => [{
                "hash" => bytes {
                    0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
                    0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
                    0x78, 0x59, 0x91, 0x63
                },
                "archive" => false
            }]
        }
    ],
    "operation-headers" => {
        "access-mechanism" => "NATIVE",
        "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
    },
    "address" => []
}
{code}

Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found".


> Deploying an empty deployment and adding content later fails in a composite
> ---------------------------------------------------------------------------
>
>                 Key: WFCORE-3479
>                 URL: https://issues.jboss.org/browse/WFCORE-3479
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.10.Final
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following:
> {code}
> 1) Create an empty deployment
> 2) Add some content to the deployment using input streams
> 3) Add the deployment to a server group
> {code}
> However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem. 
> Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "add",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{"empty" => true}]
>         },
>         {
>             "operation" => "add-content",
>             "address" => [("deployment" => "test.war")],
>             "content" => [
>                 {
>                     "target-path" => "index.html",
>                     "input-stream-index" => 0
>                 },
>                 {
>                     "target-path" => "index2.html",
>                     "input-stream-index" => 1
>                 }
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "other-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "main-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         }
>     ],
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE",
>         "domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745",
>         "execute-for-coordinator" => true
>     }
> }
> {code}
> What ends up being pushed to the slave is:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "add",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{
>                 "hash" => bytes {
>                     0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16,
>                     0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29,
>                     0x04, 0x05, 0x9d, 0x82
>                 },
>                 "archive" => false
>             }],
>             "operation-headers" => {
>                 "caller-type" => "user",
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
>             },
>             "runtime-name" => undefined
>         },
>         {
>             "operation" => "add-content",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{
>                 "hash" => bytes {
>                     0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
>                     0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
>                     0x78, 0x59, 0x91, 0x63
>                 },
>                 "target-path" => "."
>             }],
>             "operation-headers" => {
>                 "caller-type" => "user",
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
>             },
>             "path" => [
>                 "index.html",
>                 "index2.html"
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "other-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "main-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         }
>     ],
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE",
>         "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc",
>         "execute-for-coordinator" => true
>     }
> }
> {code}
> The error reported by the DC is:
> {code}
> {
>     "outcome" => "failed",
>     "result" => {
>         "step-1" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-2" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-3" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-4" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         }
>     },
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => {
>         "outcome" => "failed",
>         "result" => {
>             "step-1" => {
>                 "outcome" => "failed",
>                 "failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found",
>                 "rolled-back" => true
>             },
>             "step-2" => {"outcome" => undefined}
>         },
>         "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}},
>         "rolled-back" => true
>     }}}}}}
> }
> {code}
> Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC:
> {code}
> {
>     "operation" => "composite",
>     "steps" => [
>         {
>             "operation" => "add-content",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{
>                 "hash" => bytes {
>                     0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
>                     0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
>                     0x78, 0x59, 0x91, 0x63
>                 },
>                 "target-path" => "."
>             }],
>             "operation-headers" => {
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
>             },
>             "path" => [
>                 "index.html",
>                 "index2.html"
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [("deployment" => "test.war")],
>             "enabled" => true,
>             "operation-headers" => {
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
>             },
>             "runtime-name" => "test.war",
>             "content" => [{
>                 "hash" => bytes {
>                     0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
>                     0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
>                     0x78, 0x59, 0x91, 0x63
>                 },
>                 "archive" => false
>             }]
>         }
>     ],
>     "operation-headers" => {
>         "access-mechanism" => "NATIVE",
>         "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
>     },
>     "address" => []
> }
> {code}
> Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 17:01:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 17:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3479) Deploying an empty
 deployment and adding content later fails in a composite
In-Reply-To: <JIRA.12725935.1513892444000@Atlassian.JIRA>
References: <JIRA.12725935.1513892444000@Atlassian.JIRA>
	<JIRA.12725935.1513892444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725935.1513892444000.14856.1513893660598@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-3479:
-------------------------------
    Fix Version/s: 4.0.0.Beta1


> Deploying an empty deployment and adding content later fails in a composite
> ---------------------------------------------------------------------------
>
>                 Key: WFCORE-3479
>                 URL: https://issues.jboss.org/browse/WFCORE-3479
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.10.Final
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following:
> {code}
> 1) Create an empty deployment
> 2) Add some content to the deployment using input streams
> 3) Add the deployment to a server group
> {code}
> However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem. 
> Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "add",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{"empty" => true}]
>         },
>         {
>             "operation" => "add-content",
>             "address" => [("deployment" => "test.war")],
>             "content" => [
>                 {
>                     "target-path" => "index.html",
>                     "input-stream-index" => 0
>                 },
>                 {
>                     "target-path" => "index2.html",
>                     "input-stream-index" => 1
>                 }
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "other-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "main-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         }
>     ],
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE",
>         "domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745",
>         "execute-for-coordinator" => true
>     }
> }
> {code}
> What ends up being pushed to the slave is:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "add",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{
>                 "hash" => bytes {
>                     0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16,
>                     0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29,
>                     0x04, 0x05, 0x9d, 0x82
>                 },
>                 "archive" => false
>             }],
>             "operation-headers" => {
>                 "caller-type" => "user",
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
>             },
>             "runtime-name" => undefined
>         },
>         {
>             "operation" => "add-content",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{
>                 "hash" => bytes {
>                     0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
>                     0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
>                     0x78, 0x59, 0x91, 0x63
>                 },
>                 "target-path" => "."
>             }],
>             "operation-headers" => {
>                 "caller-type" => "user",
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
>             },
>             "path" => [
>                 "index.html",
>                 "index2.html"
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "other-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "main-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         }
>     ],
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE",
>         "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc",
>         "execute-for-coordinator" => true
>     }
> }
> {code}
> The error reported by the DC is:
> {code}
> {
>     "outcome" => "failed",
>     "result" => {
>         "step-1" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-2" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-3" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-4" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         }
>     },
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => {
>         "outcome" => "failed",
>         "result" => {
>             "step-1" => {
>                 "outcome" => "failed",
>                 "failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found",
>                 "rolled-back" => true
>             },
>             "step-2" => {"outcome" => undefined}
>         },
>         "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}},
>         "rolled-back" => true
>     }}}}}}
> }
> {code}
> Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC:
> {code}
> {
>     "operation" => "composite",
>     "steps" => [
>         {
>             "operation" => "add-content",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{
>                 "hash" => bytes {
>                     0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
>                     0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
>                     0x78, 0x59, 0x91, 0x63
>                 },
>                 "target-path" => "."
>             }],
>             "operation-headers" => {
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
>             },
>             "path" => [
>                 "index.html",
>                 "index2.html"
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [("deployment" => "test.war")],
>             "enabled" => true,
>             "operation-headers" => {
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
>             },
>             "runtime-name" => "test.war",
>             "content" => [{
>                 "hash" => bytes {
>                     0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
>                     0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
>                     0x78, 0x59, 0x91, 0x63
>                 },
>                 "archive" => false
>             }]
>         }
>     ],
>     "operation-headers" => {
>         "access-mechanism" => "NATIVE",
>         "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
>     },
>     "address" => []
> }
> {code}
> Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 17:01:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 17:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3479) Deploying an empty
 deployment and adding content later fails in a composite
In-Reply-To: <JIRA.12725935.1513892444000@Atlassian.JIRA>
References: <JIRA.12725935.1513892444000@Atlassian.JIRA>
	<JIRA.12725935.1513892444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725935.1513892444000.14861.1513893660745@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFCORE-3479:
----------------------------------

    Assignee: ehsavoie Hugonnet  (was: Brian Stansberry)


> Deploying an empty deployment and adding content later fails in a composite
> ---------------------------------------------------------------------------
>
>                 Key: WFCORE-3479
>                 URL: https://issues.jboss.org/browse/WFCORE-3479
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.10.Final
>            Reporter: Kabir Khan
>            Assignee: ehsavoie Hugonnet
>             Fix For: 4.0.0.Beta1
>
>
> When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following:
> {code}
> 1) Create an empty deployment
> 2) Add some content to the deployment using input streams
> 3) Add the deployment to a server group
> {code}
> However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem. 
> Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "add",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{"empty" => true}]
>         },
>         {
>             "operation" => "add-content",
>             "address" => [("deployment" => "test.war")],
>             "content" => [
>                 {
>                     "target-path" => "index.html",
>                     "input-stream-index" => 0
>                 },
>                 {
>                     "target-path" => "index2.html",
>                     "input-stream-index" => 1
>                 }
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "other-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "main-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         }
>     ],
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE",
>         "domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745",
>         "execute-for-coordinator" => true
>     }
> }
> {code}
> What ends up being pushed to the slave is:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "operation" => "add",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{
>                 "hash" => bytes {
>                     0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16,
>                     0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29,
>                     0x04, 0x05, 0x9d, 0x82
>                 },
>                 "archive" => false
>             }],
>             "operation-headers" => {
>                 "caller-type" => "user",
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
>             },
>             "runtime-name" => undefined
>         },
>         {
>             "operation" => "add-content",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{
>                 "hash" => bytes {
>                     0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
>                     0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
>                     0x78, 0x59, 0x91, 0x63
>                 },
>                 "target-path" => "."
>             }],
>             "operation-headers" => {
>                 "caller-type" => "user",
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
>             },
>             "path" => [
>                 "index.html",
>                 "index2.html"
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "other-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         },
>         {
>             "operation" => "add",
>             "address" => [
>                 ("server-group" => "main-server-group"),
>                 ("deployment" => "test.war")
>             ],
>             "enabled" => true
>         }
>     ],
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE",
>         "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc",
>         "execute-for-coordinator" => true
>     }
> }
> {code}
> The error reported by the DC is:
> {code}
> {
>     "outcome" => "failed",
>     "result" => {
>         "step-1" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-2" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-3" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         },
>         "step-4" => {
>             "outcome" => "failed",
>             "rolled-back" => true
>         }
>     },
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}},
>     "rolled-back" => true,
>     "server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => {
>         "outcome" => "failed",
>         "result" => {
>             "step-1" => {
>                 "outcome" => "failed",
>                 "failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found",
>                 "rolled-back" => true
>             },
>             "step-2" => {"outcome" => undefined}
>         },
>         "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}},
>         "rolled-back" => true
>     }}}}}}
> }
> {code}
> Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC:
> {code}
> {
>     "operation" => "composite",
>     "steps" => [
>         {
>             "operation" => "add-content",
>             "address" => [("deployment" => "test.war")],
>             "content" => [{
>                 "hash" => bytes {
>                     0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
>                     0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
>                     0x78, 0x59, 0x91, 0x63
>                 },
>                 "target-path" => "."
>             }],
>             "operation-headers" => {
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
>             },
>             "path" => [
>                 "index.html",
>                 "index2.html"
>             ]
>         },
>         {
>             "operation" => "add",
>             "address" => [("deployment" => "test.war")],
>             "enabled" => true,
>             "operation-headers" => {
>                 "access-mechanism" => "NATIVE",
>                 "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
>             },
>             "runtime-name" => "test.war",
>             "content" => [{
>                 "hash" => bytes {
>                     0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
>                     0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
>                     0x78, 0x59, 0x91, 0x63
>                 },
>                 "archive" => false
>             }]
>         }
>     ],
>     "operation-headers" => {
>         "access-mechanism" => "NATIVE",
>         "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
>     },
>     "address" => []
> }
> {code}
> Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 17:08:01 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 21 Dec 2017 17:08:01 -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.14890.1513894081173@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2243:
---------------------------
    Fix Version/s: 4.0.10


> 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  Thu Dec 21 17:10:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 17:10: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.14928.1513894200211@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-9634:
--------------------------------

    Assignee: ehsavoie Hugonnet  (was: Brian Stansberry)


> 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 disable this test for 7.1.0



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 17:11:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 17:11: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.14935.1513894260382@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-9634:
-----------------------------
    Description: 
I have added an
{code}
        // TODO WFLY-9634
        Assume.assumeFalse(supportManagedExplodedDeployment());
{code}
to disable this test for 7.1.0. 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.

  was:
I have added an
{code}
        // TODO WFLY-9634
        Assume.assumeFalse(supportManagedExplodedDeployment());
{code}
to disable this test for 7.1.0



> 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 disable this test for 7.1.0. 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  Thu Dec 21 17:26:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Dec 2017 17:26: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.14997.1513895160197@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-9634:
-----------------------------
    Description: 
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.

  was:
I have added an
{code}
        // TODO WFLY-9634
        Assume.assumeFalse(supportManagedExplodedDeployment());
{code}
to disable this test for 7.1.0. 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.



> 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  Thu Dec 21 18:03:00 2017
From: issues at jboss.org (andrea tarocchi (JIRA))
Date: Thu, 21 Dec 2017 18:03: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.15045.1513897380148@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507997#comment-13507997 ] 

andrea tarocchi commented on JGRP-2243:
---------------------------------------

created PRs:
* https://github.com/belaban/JGroups/pull/374
* https://github.com/belaban/JGroups/pull/375

> 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  Thu Dec 21 19:12:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 21 Dec 2017 19:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1473) Java 9: Use new
 Provider(String, String, String) constructor
In-Reply-To: <JIRA.12725941.1513901468000@Atlassian.JIRA>
References: <JIRA.12725941.1513901468000@Atlassian.JIRA>
	<JIRA.12725941.1513901468617@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725941.1513901468000.15166.1513901520133@Atlassian.JIRA>

David Lloyd created ELY-1473:
--------------------------------

             Summary: Java 9: Use new Provider(String,String,String) constructor
                 Key: ELY-1473
                 URL: https://issues.jboss.org/browse/ELY-1473
             Project: WildFly Elytron
          Issue Type: Enhancement
            Reporter: David Lloyd


Starting from Java 9, Provider instances no longer have a version of type {{double}}; instead it is a plain string.  We can start to supply the actual Elytron version string for this parameter, in Java 9.

To have Java 8 and Java 9 versions of this class, an intermediate superclass must be introduced which extends Provider, which can be overridden in a Java 9 supplement.  On Java 8, the [emulation logic|https://github.com/dmlloyd/openjdk/commit/3f86236207573314e25bf70090da5d5eeaab22c2#diff-d651c09ffa9138367a291f166bfab7f5R182] from Java 9 (or something similar) is used to construct a {{double}} from the version string.  On Java 9, the literal version string is used.

Developing a Java 9 supplement for Elytron is a prerequisite to this task.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 21 21:41:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 21 Dec 2017 21:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9479) SSL Resource Causing SSL is
	null
In-Reply-To: <JIRA.12718103.1508941219000@Atlassian.JIRA>
References: <JIRA.12718103.1508941219000@Atlassian.JIRA>
	<JIRA.12718103.1508941219000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718103.1508941219000.15317.1513910460165@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508027#comment-13508027 ] 

Stuart Douglas commented on WFLY-9479:
--------------------------------------

I was not able to reproduce this. Something is definitely closing the SSLEngine, but without a stack trace of what is happening when the engine is closed it is hard to say what it could be.

> SSL Resource Causing SSL is null
> --------------------------------
>
>                 Key: WFLY-9479
>                 URL: https://issues.jboss.org/browse/WFLY-9479
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 11.0.0.Final
>         Environment: Linux CentoOS with Docker.
>            Reporter: Jason Bruwer
>            Assignee: Stuart Douglas
>         Attachments: Screen Shot 2017-10-27 at 09.57.26.png, Screen Shot 2017-10-31 at 14.42.57.png, Screen Shot 2017-10-31 at 14.43.35.png, back_to_TLS.png, nont_ssl_server.log, server_2017-10-27T05-58-24+0000.log, showcase-master.zip, web.xml, with_openssl_chrome_server.log, with_openssl_firefox_server.log
>
>
> 2017-10-25 13:28:42,865 ERROR [io.undertow.request] (default task-20) UT005023: Exception handling request to /fluid/javax.faces.resource/syntaxhighlighter.css.xhtml: java.lang.IllegalStateException: ssl is null
> 	at org.wildfly.openssl.SSLImpl.getSessionId0(Native Method)
> 	at org.wildfly.openssl.SSLImpl.getSessionId(SSLImpl.java:479)
> 	at org.wildfly.openssl.OpenSSLEngine.getSession(OpenSSLEngine.java:871)
> 	at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.getSession(ALPNLimitingSSLEngine.java:211)
> 	at io.undertow.protocols.ssl.SslConduit.getSslSession(SslConduit.java:638)
> 	at io.undertow.protocols.ssl.UndertowSslConnection.getSslSession(UndertowSslConnection.java:69)
> 	at io.undertow.protocols.http2.Http2Channel.getSslSession(Http2Channel.java:791)
> 	at io.undertow.server.protocol.http2.Http2SslSessionInfo.getCipherSuite(Http2SslSessionInfo.java:53)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:122)
> 	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:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	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.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 	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 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)
> 2017-10-25 13:28:42,866 ERROR [io.undertow.request] (default task-32) UT005023: Exception handling request to /fluid/javax.faces.resource/layout/layout.css.xhtml: java.lang.IllegalStateException: ssl is null
> 	at org.wildfly.openssl.SSLImpl.getSessionId0(Native Method)
> 	at org.wildfly.openssl.SSLImpl.getSessionId(SSLImpl.java:479)
> 	at org.wildfly.openssl.OpenSSLEngine.getSession(OpenSSLEngine.java:871)
> 	at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.getSession(ALPNLimitingSSLEngine.java:211)
> 	at io.undertow.protocols.ssl.SslConduit.getSslSession(SslConduit.java:638)
> 	at io.undertow.protocols.ssl.UndertowSslConnection.getSslSession(UndertowSslConnection.java:69)
> 	at io.undertow.protocols.http2.Http2Channel.getSslSession(Http2Channel.java:791)
> 	at io.undertow.server.protocol.http2.Http2SslSessionInfo.getCipherSuite(Http2SslSessionInfo.java:53)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:122)
> 	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:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	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.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 	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 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)
> 2017-10-25 13:28:42,865 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /fluid/javax.faces.resource/fa/font-awesome.css.xhtml: java.lang.IllegalStateException: ssl is null
> 	at org.wildfly.openssl.SSLImpl.getSessionId0(Native Method)
> 	at org.wildfly.openssl.SSLImpl.getSessionId(SSLImpl.java:479)
> 	at org.wildfly.openssl.OpenSSLEngine.getSession(OpenSSLEngine.java:871)
> 	at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.getSession(ALPNLimitingSSLEngine.java:211)
> 	at io.undertow.protocols.ssl.SslConduit.getSslSession(SslConduit.java:638)
> 	at io.undertow.protocols.ssl.UndertowSslConnection.getSslSession(UndertowSslConnection.java:69)
> 	at io.undertow.protocols.http2.Http2Channel.getSslSession(Http2Channel.java:791)
> 	at io.undertow.server.protocol.http2.Http2SslSessionInfo.getCipherSuite(Http2SslSessionInfo.java:53)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:122)
> 	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:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	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.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 	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 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)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 22 04:37:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Fri, 22 Dec 2017 04:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9635) jdr throws
 IllegalArgumentException if server is not started
In-Reply-To: <JIRA.12725956.1513935393000@Atlassian.JIRA>
References: <JIRA.12725956.1513935393000@Atlassian.JIRA>
	<JIRA.12725956.1513935393714@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725956.1513935393000.15690.1513935420218@Atlassian.JIRA>

Marek Kopeck? created WFLY-9635:
-----------------------------------

             Summary: jdr throws IllegalArgumentException if server is not started
                 Key: WFLY-9635
                 URL: https://issues.jboss.org/browse/WFLY-9635
             Project: WildFly
          Issue Type: Bug
          Components: JDR
            Reporter: Marek Kopeck?
            Assignee: Brad Maxwell
            Priority: Blocker


*Description of the issue:*
jdr throws IllegalArgumentException if server is not started

*Steps to reproduce:*
# do *not* start the server
# ./jdr.sh

*Actual results:*
{noformat}
[mkopecky at dhcp-10-40-4-226 bin]$ ./jdr.sh
Initializing JBoss Diagnostic Reporter...
Trying to connect to http-remoting localhost:9990
Starting embedded server
Exception for embed-server --std-out=echo : Task java.util.concurrent.FutureTask at 6631f5ca rejected from java.util.concurrent.ThreadPoolExecutor at 5ace1ed4[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
Exception for stop-embedded-server: Task java.util.concurrent.FutureTask at 31e5415e rejected from java.util.concurrent.ThreadPoolExecutor at 5ace1ed4[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
Exception in thread "main" java.lang.IllegalArgumentException: Error handling command: /subsystem=jdr:generate-jdr-report()
	at org.jboss.as.cli.scriptsupport.CLI.cmd(CLI.java:248)
	at org.jboss.as.jdr.CommandLineMain.main(CommandLineMain.java:120)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
Caused by: org.jboss.as.cli.CommandLineException: The connection to the controller has not been established.
	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:804)
	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:823)
	at org.jboss.as.cli.scriptsupport.CLI.cmd(CLI.java:241)
	... 3 more
[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  Fri Dec 22 05:12:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Fri, 22 Dec 2017 05:12: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.1513937508000@Atlassian.JIRA>
References: <JIRA.12725960.1513937508000@Atlassian.JIRA>
	<JIRA.12725960.1513937508799@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725960.1513937508000.15869.1513937520471@Atlassian.JIRA>

Marek Kopeck? created WFCORE-3480:
-------------------------------------

             Summary: 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  Fri Dec 22 06:01:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 22 Dec 2017 06:01: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.15985.1513940460184@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508106#comment-13508106 ] 

Jean-Francois Denise commented on WFCORE-3480:
----------------------------------------------

Good catch! The fix for AESH-435 was not applied to aesh-readline, I fixed it and opened a PR. We will need to upgrade to aesh-readline 1.3

> 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  Fri Dec 22 06:24:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 22 Dec 2017 06:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869011000@Atlassian.JIRA>
References: <JIRA.12725867.1513869011000@Atlassian.JIRA>
	<JIRA.12725867.1513869011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869011000.16002.1513941840077@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508109#comment-13508109 ] 

Jan Kalina commented on ELY-1472:
---------------------------------

Following path of OpenJDK fixes the issue:
{code}
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c:
   // initialize addrtype in CB first
   cb->initiator_addrtype = GSS_C_AF_NULLADDR;
   cb->acceptor_addrtype = GSS_C_AF_NULLADDR;
+  // addresses needs to be initialized to empty
+  cb->initiator_address.length = 0;
+  cb->initiator_address.value = NULL;
+  cb->acceptor_address.length = 0;
+  cb->acceptor_address.value = NULL;
{code}

> [native kerberos] setting channelBinding of gssContext when not used
> --------------------------------------------------------------------
>
>                 Key: ELY-1472
>                 URL: https://issues.jboss.org/browse/ELY-1472
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: kerberos
>
> Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used.
> This lead to following error when using native Kerberos library:
> {code}
> [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
> [GSSLibStub_acceptContext] before3: inToken.length=515
> [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
> [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
> [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
> c/r/s = 0/4/0
> {code}
> Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.
> This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 22 07:27:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 22 Dec 2017 07:27: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.16065.1513945620219@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-283:
---------------------------
    Attachment: jkalina-openjdk-native-gss.patch


> 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
>
>
> 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  Fri Dec 22 07:28:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 22 Dec 2017 07:28: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.16070.1513945680140@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508118#comment-13508118 ] 

Jan Kalina commented on ELY-283:
--------------------------------

Ok, I have no idea what was the problem with minor, but it looks it is irrelevant after resolving ELY-1472 (which was actually also variable initialization bug in JDK).

The gssproxy is now successfully working, after applying OpenJDK patch  [^jkalina-openjdk-native-gss.patch] :)

> 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
>
>
> 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  Fri Dec 22 08:24:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 22 Dec 2017 08:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2197) When a declared type is
 modified during an incremental compilation the old version isn't evicted
 from the TypeResolver cache
In-Reply-To: <JIRA.12725971.1513949017000@Atlassian.JIRA>
References: <JIRA.12725971.1513949017000@Atlassian.JIRA>
	<JIRA.12725971.1513949017759@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725971.1513949017000.16272.1513949040351@Atlassian.JIRA>

Mario Fusco created DROOLS-2197:
-----------------------------------

             Summary: When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache
                 Key: DROOLS-2197
                 URL: https://issues.jboss.org/browse/DROOLS-2197
             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 Dec 22 08:28:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 22 Dec 2017 08:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2197) When a declared type is
 modified during an incremental compilation the old version isn't evicted
 from the TypeResolver cache
In-Reply-To: <JIRA.12725971.1513949018000@Atlassian.JIRA>
References: <JIRA.12725971.1513949018000@Atlassian.JIRA>
	<JIRA.12725971.1513949018000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725971.1513949018000.16281.1513949280281@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508128#comment-13508128 ] 

Mario Fusco commented on DROOLS-2197:
-------------------------------------

When a declared type is modified during an incremental compilation the compiled class of the old version isn't evicted from the TypeResolver cache and then the knowledge builder keep seeing that older version.

> When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2197
>                 URL: https://issues.jboss.org/browse/DROOLS-2197
>             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 Dec 22 09:24:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 22 Dec 2017 09:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2197) When a declared type is
 modified during an incremental compilation the old version isn't evicted
 from the TypeResolver cache
In-Reply-To: <JIRA.12725971.1513949018000@Atlassian.JIRA>
References: <JIRA.12725971.1513949018000@Atlassian.JIRA>
	<JIRA.12725971.1513949018000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725971.1513949018000.16426.1513952640110@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2197.
---------------------------------
    Resolution: Done


Fixed by https://github.com/kiegroup/drools/commit/31be4b3979d7ea9aebfdbe6917f5e6be1e783fa5

> When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2197
>                 URL: https://issues.jboss.org/browse/DROOLS-2197
>             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 Dec 22 09:53:00 2017
From: issues at jboss.org (Martin Weiler (JIRA))
Date: Fri, 22 Dec 2017 09:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2198) [GSS](6.4.z) When a
 declared type is modified during an incremental compilation the old version
 isn't evicted from the TypeResolver cache
In-Reply-To: <JIRA.12725989.1513954373000@Atlassian.JIRA>
References: <JIRA.12725989.1513954373000@Atlassian.JIRA>
	<JIRA.12725989.1513954373984@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725989.1513954373000.16482.1513954380145@Atlassian.JIRA>

Martin Weiler created DROOLS-2198:
-------------------------------------

             Summary: [GSS](6.4.z) When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache
                 Key: DROOLS-2198
                 URL: https://issues.jboss.org/browse/DROOLS-2198
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Martin Weiler
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 22 11:04:00 2017
From: issues at jboss.org (peter craddock (JIRA))
Date: Fri, 22 Dec 2017 11: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.1513958594000@Atlassian.JIRA>
References: <JIRA.12725992.1513958594000@Atlassian.JIRA>
	<JIRA.12725992.1513958594533@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725992.1513958594000.16618.1513958640172@Atlassian.JIRA>

peter craddock created WFLY-9636:
------------------------------------

             Summary: 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


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  Fri Dec 22 11:47:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 22 Dec 2017 11: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.16639.1513961220204@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-283:
---------------------------
    Attachment: reproducer-gss.zip


> 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  Fri Dec 22 11:49:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 22 Dec 2017 11:49: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.16644.1513961340147@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508167#comment-13508167 ] 

Jan Kalina commented on ELY-283:
--------------------------------

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  Fri Dec 22 11:53:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 22 Dec 2017 11:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1472) [native kerberos] setting
 channelBinding of gssContext when not used
In-Reply-To: <JIRA.12725867.1513869011000@Atlassian.JIRA>
References: <JIRA.12725867.1513869011000@Atlassian.JIRA>
	<JIRA.12725867.1513869011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725867.1513869011000.16647.1513961580112@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-1472.
---------------------------
    Resolution: Rejected


Fixing patch of JDK in ELY-283:
https://issues.jboss.org/secure/attachment/12429366/jkalina-openjdk-native-gss.patch
Closing this, as this is not Elytron issue actually.

> [native kerberos] setting channelBinding of gssContext when not used
> --------------------------------------------------------------------
>
>                 Key: ELY-1472
>                 URL: https://issues.jboss.org/browse/ELY-1472
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: kerberos
>
> Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used.
> This lead to following error when using native Kerberos library:
> {code}
> [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0
> [GSSLibStub_acceptContext] before3: inToken.length=515
> [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0
> [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12
> [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12
> c/r/s = 0/4/0
> {code}
> Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied.
> This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Dec 22 12:16:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 22 Dec 2017 12:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2199) Rule units are executed in
 reverse order when a consequence calls a sequence of drools.run(unit)
In-Reply-To: <JIRA.12725994.1513962901000@Atlassian.JIRA>
References: <JIRA.12725994.1513962901000@Atlassian.JIRA>
	<JIRA.12725994.1513962901308@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725994.1513962901000.16655.1513962960180@Atlassian.JIRA>

Mario Fusco created DROOLS-2199:
-----------------------------------

             Summary: Rule units are executed in reverse order when a consequence calls a sequence of drools.run(unit)
                 Key: DROOLS-2199
                 URL: https://issues.jboss.org/browse/DROOLS-2199
             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 Dec 22 12:26:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 22 Dec 2017 12:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2199) Rule units are executed in
 reverse order when a consequence calls a sequence of drools.run(unit)
In-Reply-To: <JIRA.12725994.1513962901000@Atlassian.JIRA>
References: <JIRA.12725994.1513962901000@Atlassian.JIRA>
	<JIRA.12725994.1513962901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725994.1513962901000.16665.1513963560105@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2199.
---------------------------------
    Resolution: Done


Fixed by https://github.com/kiegroup/drools/commit/a1d778bcb93658f98ab0bac10a520dc855688ecc

> Rule units are executed in reverse order when a consequence calls a sequence of drools.run(unit)
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2199
>                 URL: https://issues.jboss.org/browse/DROOLS-2199
>             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  Sat Dec 23 11:43:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 23 Dec 2017 11:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9637) Remove uses of "new
 OperationFailedException(ModelNode)"
In-Reply-To: <JIRA.12726004.1514047320000@Atlassian.JIRA>
References: <JIRA.12726004.1514047320000@Atlassian.JIRA>
	<JIRA.12726004.1514047320336@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726004.1514047320000.16834.1514047380095@Atlassian.JIRA>

Brian Stansberry created WFLY-9637:
--------------------------------------

             Summary: Remove uses of "new OperationFailedException(ModelNode)"
                 Key: WFLY-9637
                 URL: https://issues.jboss.org/browse/WFLY-9637
             Project: WildFly
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


Constructor is deprecated; remove use of it so we can eventually drop it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Dec 23 11:50:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 23 Dec 2017 11:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9638) Remove uses of "new
 OperationFailedException(ModelNode)"
In-Reply-To: <JIRA.12726005.1514047749000@Atlassian.JIRA>
References: <JIRA.12726005.1514047749000@Atlassian.JIRA>
	<JIRA.12726005.1514047749528@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726005.1514047749000.16836.1514047800165@Atlassian.JIRA>

Brian Stansberry created WFLY-9638:
--------------------------------------

             Summary: Remove uses of "new OperationFailedException(ModelNode)"
                 Key: WFLY-9638
                 URL: https://issues.jboss.org/browse/WFLY-9638
             Project: WildFly
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


Constructor is deprecated; remove use of it so we can eventually drop it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Dec 23 11:50:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 23 Dec 2017 11:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3481) Remove uses of "new
 OperationFailedException(ModelNode)"
In-Reply-To: <JIRA.12726005.1514047750000@Atlassian.JIRA>
References: <JIRA.12726005.1514047750000@Atlassian.JIRA>
	<JIRA.12726005.1514047750000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726005.1514047750000.16838.1514047800299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-9638 to WFCORE-3481:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-3481  (was: WFLY-9638)
    Component/s: Domain Management
                     (was: Domain Management)


> Remove uses of "new OperationFailedException(ModelNode)"
> --------------------------------------------------------
>
>                 Key: WFCORE-3481
>                 URL: https://issues.jboss.org/browse/WFCORE-3481
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> Constructor is deprecated; remove use of it so we can eventually drop it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Dec 23 11:50:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 23 Dec 2017 11:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3481) Remove uses of "new
 OperationFailedException(ModelNode)"
In-Reply-To: <JIRA.12726005.1514047750000@Atlassian.JIRA>
References: <JIRA.12726005.1514047750000@Atlassian.JIRA>
	<JIRA.12726005.1514047750000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726005.1514047750000.16840.1514047800374@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3481:
-------------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/10731)


> Remove uses of "new OperationFailedException(ModelNode)"
> --------------------------------------------------------
>
>                 Key: WFCORE-3481
>                 URL: https://issues.jboss.org/browse/WFCORE-3481
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> Constructor is deprecated; remove use of it so we can eventually drop it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Dec 23 13:37:00 2017
From: issues at jboss.org (Rajendra Mallampati (JIRA))
Date: Sat, 23 Dec 2017 13:37: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.1514054209000@Atlassian.JIRA>
References: <JIRA.12726006.1514054209000@Atlassian.JIRA>
	<JIRA.12726006.1514054209949@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726006.1514054209000.16853.1514054220350@Atlassian.JIRA>

Rajendra Mallampati created WFLY-9639:
-----------------------------------------

             Summary: 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: Application Client
    Affects Versions: 9.x.x TBD
         Environment: RHEL 7.2, JDK 1.8_144
            Reporter: Rajendra Mallampati
            Assignee: Stuart Douglas


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  Sat Dec 23 17:50:00 2017
From: issues at jboss.org (dbdbdb dbdbdb (JIRA))
Date: Sat, 23 Dec 2017 17:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9640) Configuring deployment
 runtime name with XML
In-Reply-To: <JIRA.12726007.1514069354000@Atlassian.JIRA>
References: <JIRA.12726007.1514069354000@Atlassian.JIRA>
	<JIRA.12726007.1514069354732@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726007.1514069354000.16926.1514069400209@Atlassian.JIRA>

dbdbdb dbdbdb created WFLY-9640:
-----------------------------------

             Summary: Configuring deployment runtime name with XML
                 Key: WFLY-9640
                 URL: https://issues.jboss.org/browse/WFLY-9640
             Project: WildFly
          Issue Type: Feature Request
          Components: Application Client, Server
    Affects Versions: 11.0.0.Final, 10.1.0.Final
            Reporter: dbdbdb dbdbdb
            Assignee: Stuart Douglas


Wildfly should have a option to define the name and runtime name of a web application (.war) in a XML file.
Like jboss-web.xml and ejb-jar.xml, it would be great if we can set the runtime name in a XML whatever the .war filename is.
Very useful not only to prevent human error when deploying via web console (fill the upload form with wrong runtime name), but also useful when the applications is deployed by copying the .war file into deployments directory.

The correct runtime name is important because Wildfly use this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was serialized before.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Dec 23 19:13:00 2017
From: issues at jboss.org (dbdbdb dbdbdb (JIRA))
Date: Sat, 23 Dec 2017 19:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9640) Configuring deployment
 runtime name with XML
In-Reply-To: <JIRA.12726007.1514069355000@Atlassian.JIRA>
References: <JIRA.12726007.1514069355000@Atlassian.JIRA>
	<JIRA.12726007.1514069355000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726007.1514069355000.16964.1514074380197@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

dbdbdb dbdbdb updated WFLY-9640:
--------------------------------
    Description: 
In my opinion, Wildfly should have an option to define the name and runtime name of a web application (.war) in a XML file.
Like jboss-web.xml and ejb-jar.xml, it would be great if we could set the runtime name in a XML whatever the .war filename is. It would be
very useful, not only to prevent human error when deploying via web console (filling the upload form with wrong runtime name), but also  when the applications are deployed by copying the .war file into deployments directory.

The correct runtime name is important because Wildfly uses this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was previously serialized.

  was:
Wildfly should have a option to define the name and runtime name of a web application (.war) in a XML file.
Like jboss-web.xml and ejb-jar.xml, it would be great if we can set the runtime name in a XML whatever the .war filename is.
Very useful not only to prevent human error when deploying via web console (fill the upload form with wrong runtime name), but also useful when the applications is deployed by copying the .war file into deployments directory.

The correct runtime name is important because Wildfly use this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was serialized before.



> Configuring deployment runtime name with XML
> --------------------------------------------
>
>                 Key: WFLY-9640
>                 URL: https://issues.jboss.org/browse/WFLY-9640
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Application Client, Server
>    Affects Versions: 10.1.0.Final, 11.0.0.Final
>            Reporter: dbdbdb dbdbdb
>            Assignee: Stuart Douglas
>
> In my opinion, Wildfly should have an option to define the name and runtime name of a web application (.war) in a XML file.
> Like jboss-web.xml and ejb-jar.xml, it would be great if we could set the runtime name in a XML whatever the .war filename is. It would be
> very useful, not only to prevent human error when deploying via web console (filling the upload form with wrong runtime name), but also  when the applications are deployed by copying the .war file into deployments directory.
> The correct runtime name is important because Wildfly uses this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was previously serialized.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Dec 23 19:15:00 2017
From: issues at jboss.org (dbdbdb dbdbdb (JIRA))
Date: Sat, 23 Dec 2017 19:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9640) Configuring deployment
 runtime name with XML
In-Reply-To: <JIRA.12726007.1514069355000@Atlassian.JIRA>
References: <JIRA.12726007.1514069355000@Atlassian.JIRA>
	<JIRA.12726007.1514069355000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726007.1514069355000.16967.1514074500129@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

dbdbdb dbdbdb updated WFLY-9640:
--------------------------------
    Description: 
In my opinion, Wildfly should have an option to define the name and runtime name of a web application (.war) in a XML file.
Like jboss-web.xml and ejb-jar.xml, it would be great if we could set the runtime name in a XML whatever the .war filename is. It would be very useful, not only to prevent human error when deploying via web console (filling the upload form with wrong runtime name), but also  when the applications are deployed by copying the .war file into deployments directory.

The correct runtime name is important because Wildfly uses this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was previously serialized.

  was:
In my opinion, Wildfly should have an option to define the name and runtime name of a web application (.war) in a XML file.
Like jboss-web.xml and ejb-jar.xml, it would be great if we could set the runtime name in a XML whatever the .war filename is. It would be
very useful, not only to prevent human error when deploying via web console (filling the upload form with wrong runtime name), but also  when the applications are deployed by copying the .war file into deployments directory.

The correct runtime name is important because Wildfly uses this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was previously serialized.



> Configuring deployment runtime name with XML
> --------------------------------------------
>
>                 Key: WFLY-9640
>                 URL: https://issues.jboss.org/browse/WFLY-9640
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Application Client, Server
>    Affects Versions: 10.1.0.Final, 11.0.0.Final
>            Reporter: dbdbdb dbdbdb
>            Assignee: Stuart Douglas
>
> In my opinion, Wildfly should have an option to define the name and runtime name of a web application (.war) in a XML file.
> Like jboss-web.xml and ejb-jar.xml, it would be great if we could set the runtime name in a XML whatever the .war filename is. It would be very useful, not only to prevent human error when deploying via web console (filling the upload form with wrong runtime name), but also  when the applications are deployed by copying the .war file into deployments directory.
> The correct runtime name is important because Wildfly uses this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was previously serialized.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Dec 23 22:59:00 2017
From: issues at jboss.org (Fred Ling (JIRA))
Date: Sat, 23 Dec 2017 22:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9641) Cluster EJB can not work with
	"-b 0.0.0.0"
In-Reply-To: <JIRA.12726008.1514087887000@Atlassian.JIRA>
References: <JIRA.12726008.1514087887000@Atlassian.JIRA>
	<JIRA.12726008.1514087887306@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726008.1514087887000.16969.1514087940079@Atlassian.JIRA>

Fred Ling created WFLY-9641:
-------------------------------

             Summary: Cluster EJB can not work with "-b 0.0.0.0"
                 Key: WFLY-9641
                 URL: https://issues.jboss.org/browse/WFLY-9641
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 11.0.0.Final
            Reporter: Fred Ling


The ejb cluster does not work when bind to 0.0.0.0, using --server-config=standalone-full-ha.xml -b 0.0.0.0.
The ejb client fails to connect to the cluster nodes because it tries to connect to 0.0.0.0.
For more information please refer to the forum thread.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Dec 24 11:07:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 24 Dec 2017 11:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9640) Configuring deployment
 runtime name with XML
In-Reply-To: <JIRA.12726007.1514069355000@Atlassian.JIRA>
References: <JIRA.12726007.1514069355000@Atlassian.JIRA>
	<JIRA.12726007.1514069355000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726007.1514069355000.16979.1514131620366@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-9640.
------------------------------------
      Assignee: Brian Stansberry  (was: Stuart Douglas)
    Resolution: Won't Do


The runtime name needs to be known before any code that could extract it from a deployment descriptor etc could run.

The runtime name can be set in standalone.xml (or domain.xml in a managed domain.)

> Configuring deployment runtime name with XML
> --------------------------------------------
>
>                 Key: WFLY-9640
>                 URL: https://issues.jboss.org/browse/WFLY-9640
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Application Client, Server
>    Affects Versions: 10.1.0.Final, 11.0.0.Final
>            Reporter: dbdbdb dbdbdb
>            Assignee: Brian Stansberry
>
> In my opinion, Wildfly should have an option to define the name and runtime name of a web application (.war) in a XML file.
> Like jboss-web.xml and ejb-jar.xml, it would be great if we could set the runtime name in a XML whatever the .war filename is. It would be very useful, not only to prevent human error when deploying via web console (filling the upload form with wrong runtime name), but also  when the applications are deployed by copying the .war file into deployments directory.
> The correct runtime name is important because Wildfly uses this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was previously serialized.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Dec 25 19:32:00 2017
From: issues at jboss.org (Hiroaki Naito (JIRA))
Date: Mon, 25 Dec 2017 19:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9642) CVE-2016-9589
In-Reply-To: <JIRA.12726019.1514248262000@Atlassian.JIRA>
References: <JIRA.12726019.1514248262000@Atlassian.JIRA>
	<JIRA.12726019.1514248262740@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726019.1514248262000.17170.1514248320142@Atlassian.JIRA>

Hiroaki Naito created WFLY-9642:
-----------------------------------

             Summary: CVE-2016-9589
                 Key: WFLY-9642
                 URL: https://issues.jboss.org/browse/WFLY-9642
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Hiroaki Naito
            Assignee: Jason Greene
            Priority: Critical






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Dec 26 04:24:00 2017
From: issues at jboss.org (Francis ANDRE (JIRA))
Date: Tue, 26 Dec 2017 04:24: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.1514280204019@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726024.1514280204000.17241.1514280240238@Atlassian.JIRA>

Francis ANDRE created JBJCA-1363:
------------------------------------

             Summary: 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.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  Tue Dec 26 08:09:00 2017
From: issues at jboss.org (Francis ANDRE (JIRA))
Date: Tue, 26 Dec 2017 08:09: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.17291.1514293740245@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francis ANDRE updated JBJCA-1363:
---------------------------------
    Priority: Critical  (was: Major)


> 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.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
>            Priority: Critical
>
> 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  Tue Dec 26 08:09:00 2017
From: issues at jboss.org (Francis ANDRE (JIRA))
Date: Tue, 26 Dec 2017 08:09: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.17294.1514293740302@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508259#comment-13508259 ] 

Francis ANDRE commented on JBJCA-1363:
--------------------------------------

This issue appears also in ironjacamar-1.0.17 in which I more interested since I am wokring with JBoss-EAP-6.1.

> 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.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
>            Priority: Critical
>
> 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  Tue Dec 26 08:10:00 2017
From: issues at jboss.org (Francis ANDRE (JIRA))
Date: Tue, 26 Dec 2017 08:10: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.17297.1514293800205@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francis ANDRE updated JBJCA-1363:
---------------------------------
    Affects Version/s: 1.0.17.Final


> 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
>            Priority: Critical
>
> 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  Tue Dec 26 13:06:00 2017
From: issues at jboss.org (Francis ANDRE (JIRA))
Date: Tue, 26 Dec 2017 13:06: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.17329.1514311560269@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francis ANDRE updated JBJCA-1363:
---------------------------------
    Priority: Blocker  (was: Critical)


> 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
>            Priority: Blocker
>
> 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  Tue Dec 26 13:11:00 2017
From: issues at jboss.org (Francis ANDRE (JIRA))
Date: Tue, 26 Dec 2017 13:11: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.17332.1514311860331@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508264#comment-13508264 ] 

Francis ANDRE commented on JBJCA-1363:
--------------------------------------

Hi

I am trying to understand with the ironjacamar-1.0.17-Final server why my EIS RA is not activated when used under JBoss-eap-6.1. 

This exception is blocking the deployment of my EIS RA -- scortcicsecirar-3.1.0.rar -- on the  ironjacamar-1.0.17-Final server, precluding any debugging I can make with ironjacamar-1.0.17-Final.

For information, below is the server.log from a standalone JBoss-eap-6.1 configuration.

19:03:59,804 DEBUG [org.jboss.as.connector.logging] (MSC service thread 1-3) starting Inactive:InactiveResourceAdapterDeployment{module=Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader, connectorXmlDescriptor=org.jboss.as.connector.metadata.xmldescriptors.ConnectorXmlDescriptor at 61b97010, deployment='AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0', deploymentUnitName='AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0.rar', registration=org.jboss.as.controller.registry.ConcreteResourceRegistration at 556c5c8f, serviceTarget=org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget at 3d30dc19}
19:03:59,820 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) IJ020001: Required license terms for file:/C:/ProgramFiles/JBoss/jboss-eap-6.1/standalone/deployments/AcctFtCics-ear-1.0.0.ear/scortcicsecirar-3.1.0.rar/
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><description>Resource Adapter for accessing CICS through CTG (CICS Transaction Gateway)</description><display-name>Resource Adapter for CICS Transaction Gateway</display-name><vendor-name>SCORT S.A.</vendor-name><eis-type>CICS via CTG</eis-type><license><license-required>true</license-required></license><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.scort.ctg.cics.eci.jca.EciResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory</managedconnectionfactory-class><config-property><description>URL of the CTG</description><config-property-name>connectionUrl</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><description>Server (CICS) Name</description><config-property-name>serverName</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.scort.ctg.cics.eci.jca.EciConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.scort.ctg.cics.eci.jca.EciConnection</connection-impl-class></connection-definition><transaction-support>LocalTransaction</transaction-support><authentication-mechanism><authentication-mechanism-type>BasicPassword</authentication-mechanism-type><credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface></authentication-mechanism><reauthentication-support>true</reauthentication-support></outbound-resourceadapter></resourceadapter></connector>
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) IronJacamar=null
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) RaXML=null
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) ActivateDeployment=false
19:03:59,820 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) CdMeta: <connection-definition><managedconnectionfactory-class>com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory</managedconnectionfactory-class><config-property><description>URL of the CTG</description><config-property-name>connectionUrl</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><description>Server (CICS) Name</description><config-property-name>serverName</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.scort.ctg.cics.eci.jca.EciConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.scort.ctg.cics.eci.jca.EciConnection</connection-impl-class></connection-definition>
19:03:59,820 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-4) Exception during unregistering deployment: org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0 isn't registered
	at org.jboss.jca.core.mdr.SimpleMetadataRepository.unregisterResourceAdapter(SimpleMetadataRepository.java:117) [ironjacamar-core-impl-1.0.17.Final-redhat-1.jar:1.0.17.Final-redhat-1]
	at org.jboss.as.connector.services.mdr.AS7MetadataRepositoryImpl.unregisterResourceAdapter(AS7MetadataRepositoryImpl.java:66)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.unregisterAll(ResourceAdapterDeploymentService.java:165)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:115)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]

19:03:59,835 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.ra.deployer."AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0": org.jboss.msc.service.StartException in service jboss.ra.deployer."AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0": JBAS010446: N'a pas pu d?marrer le d?ploiement RA [AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0]
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:116)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]
Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/C:/ProgramFiles/JBoss/jboss-eap-6.1/standalone/deployments/AcctFtCics-ear-1.0.0.ear/scortcicsecirar-3.1.0.rar/
	at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2449)
	at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:1104)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$AS7RaDeployer.doDeploy(ResourceAdapterDeploymentService.java:197)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:112)
	... 5 more
Caused by: org.jboss.jca.validator.ValidatorException: Severity: ERROR
Section: 6.5.3.2
Description: A ManagedConnectionFactory must be a non-null instance.
Code: com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory (ModuleClassLoader for Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader)

Severity: ERROR
Section: 5.3.1
Description: A ResourceAdapter must be a non-null instance.
Code: com.scort.ctg.cics.eci.jca.EciResourceAdapter (ModuleClassLoader for Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader)


> 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
>            Priority: Blocker
>
> 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  Wed Dec 27 02:41:00 2017
From: issues at jboss.org (Francis ANDRE (JIRA))
Date: Wed, 27 Dec 2017 02:41: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.17386.1514360460401@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508264#comment-13508264 ] 

Francis ANDRE edited comment on JBJCA-1363 at 12/27/17 2:40 AM:
----------------------------------------------------------------

Hi

I am trying to understand why my EIS RA is not activated when used under JBoss-eap-6.1 using ALL trace logs in the ironjacamar-1.0.17-Final server. 

This exception is blocking the deployment of my EIS RA -- scortcicsecirar-3.1.0.rar -- on the  ironjacamar-1.0.17-Final server, precluding any debugging I can make with ironjacamar-1.0.17-Final.

For information, below is the server.log from a standalone JBoss-eap-6.1 configuration.

19:03:59,804 DEBUG [org.jboss.as.connector.logging] (MSC service thread 1-3) starting Inactive:InactiveResourceAdapterDeployment{module=Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader, connectorXmlDescriptor=org.jboss.as.connector.metadata.xmldescriptors.ConnectorXmlDescriptor at 61b97010, deployment='AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0', deploymentUnitName='AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0.rar', registration=org.jboss.as.controller.registry.ConcreteResourceRegistration at 556c5c8f, serviceTarget=org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget at 3d30dc19}
19:03:59,820 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) IJ020001: Required license terms for file:/C:/ProgramFiles/JBoss/jboss-eap-6.1/standalone/deployments/AcctFtCics-ear-1.0.0.ear/scortcicsecirar-3.1.0.rar/
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><description>Resource Adapter for accessing CICS through CTG (CICS Transaction Gateway)</description><display-name>Resource Adapter for CICS Transaction Gateway</display-name><vendor-name>SCORT S.A.</vendor-name><eis-type>CICS via CTG</eis-type><license><license-required>true</license-required></license><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.scort.ctg.cics.eci.jca.EciResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory</managedconnectionfactory-class><config-property><description>URL of the CTG</description><config-property-name>connectionUrl</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><description>Server (CICS) Name</description><config-property-name>serverName</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.scort.ctg.cics.eci.jca.EciConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.scort.ctg.cics.eci.jca.EciConnection</connection-impl-class></connection-definition><transaction-support>LocalTransaction</transaction-support><authentication-mechanism><authentication-mechanism-type>BasicPassword</authentication-mechanism-type><credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface></authentication-mechanism><reauthentication-support>true</reauthentication-support></outbound-resourceadapter></resourceadapter></connector>
*19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) IronJacamar=null
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) RaXML=null
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) ActivateDeployment=false*
19:03:59,820 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) CdMeta: <connection-definition><managedconnectionfactory-class>com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory</managedconnectionfactory-class><config-property><description>URL of the CTG</description><config-property-name>connectionUrl</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><description>Server (CICS) Name</description><config-property-name>serverName</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.scort.ctg.cics.eci.jca.EciConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.scort.ctg.cics.eci.jca.EciConnection</connection-impl-class></connection-definition>
19:03:59,820 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-4) Exception during unregistering deployment: org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0 isn't registered
	at org.jboss.jca.core.mdr.SimpleMetadataRepository.unregisterResourceAdapter(SimpleMetadataRepository.java:117) [ironjacamar-core-impl-1.0.17.Final-redhat-1.jar:1.0.17.Final-redhat-1]
	at org.jboss.as.connector.services.mdr.AS7MetadataRepositoryImpl.unregisterResourceAdapter(AS7MetadataRepositoryImpl.java:66)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.unregisterAll(ResourceAdapterDeploymentService.java:165)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:115)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]

19:03:59,835 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.ra.deployer."AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0": org.jboss.msc.service.StartException in service jboss.ra.deployer."AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0": JBAS010446: N'a pas pu d?marrer le d?ploiement RA [AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0]
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:116)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]
Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/C:/ProgramFiles/JBoss/jboss-eap-6.1/standalone/deployments/AcctFtCics-ear-1.0.0.ear/scortcicsecirar-3.1.0.rar/
	at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2449)
	at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:1104)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$AS7RaDeployer.doDeploy(ResourceAdapterDeploymentService.java:197)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:112)
	... 5 more
Caused by: org.jboss.jca.validator.ValidatorException: Severity: ERROR
Section: 6.5.3.2
Description: A ManagedConnectionFactory must be a non-null instance.
Code: com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory (ModuleClassLoader for Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader)

Severity: ERROR
Section: 5.3.1
Description: A ResourceAdapter must be a non-null instance.
Code: com.scort.ctg.cics.eci.jca.EciResourceAdapter (ModuleClassLoader for Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader)



was (Author: fandremxw):
Hi

I am trying to understand with the ironjacamar-1.0.17-Final server why my EIS RA is not activated when used under JBoss-eap-6.1. 

This exception is blocking the deployment of my EIS RA -- scortcicsecirar-3.1.0.rar -- on the  ironjacamar-1.0.17-Final server, precluding any debugging I can make with ironjacamar-1.0.17-Final.

For information, below is the server.log from a standalone JBoss-eap-6.1 configuration.

19:03:59,804 DEBUG [org.jboss.as.connector.logging] (MSC service thread 1-3) starting Inactive:InactiveResourceAdapterDeployment{module=Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader, connectorXmlDescriptor=org.jboss.as.connector.metadata.xmldescriptors.ConnectorXmlDescriptor at 61b97010, deployment='AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0', deploymentUnitName='AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0.rar', registration=org.jboss.as.controller.registry.ConcreteResourceRegistration at 556c5c8f, serviceTarget=org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget at 3d30dc19}
19:03:59,820 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) IJ020001: Required license terms for file:/C:/ProgramFiles/JBoss/jboss-eap-6.1/standalone/deployments/AcctFtCics-ear-1.0.0.ear/scortcicsecirar-3.1.0.rar/
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><description>Resource Adapter for accessing CICS through CTG (CICS Transaction Gateway)</description><display-name>Resource Adapter for CICS Transaction Gateway</display-name><vendor-name>SCORT S.A.</vendor-name><eis-type>CICS via CTG</eis-type><license><license-required>true</license-required></license><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.scort.ctg.cics.eci.jca.EciResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory</managedconnectionfactory-class><config-property><description>URL of the CTG</description><config-property-name>connectionUrl</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><description>Server (CICS) Name</description><config-property-name>serverName</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.scort.ctg.cics.eci.jca.EciConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.scort.ctg.cics.eci.jca.EciConnection</connection-impl-class></connection-definition><transaction-support>LocalTransaction</transaction-support><authentication-mechanism><authentication-mechanism-type>BasicPassword</authentication-mechanism-type><credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface></authentication-mechanism><reauthentication-support>true</reauthentication-support></outbound-resourceadapter></resourceadapter></connector>
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) IronJacamar=null
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) RaXML=null
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) ActivateDeployment=false
19:03:59,820 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) CdMeta: <connection-definition><managedconnectionfactory-class>com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory</managedconnectionfactory-class><config-property><description>URL of the CTG</description><config-property-name>connectionUrl</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><description>Server (CICS) Name</description><config-property-name>serverName</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.scort.ctg.cics.eci.jca.EciConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.scort.ctg.cics.eci.jca.EciConnection</connection-impl-class></connection-definition>
19:03:59,820 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-4) Exception during unregistering deployment: org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0 isn't registered
	at org.jboss.jca.core.mdr.SimpleMetadataRepository.unregisterResourceAdapter(SimpleMetadataRepository.java:117) [ironjacamar-core-impl-1.0.17.Final-redhat-1.jar:1.0.17.Final-redhat-1]
	at org.jboss.as.connector.services.mdr.AS7MetadataRepositoryImpl.unregisterResourceAdapter(AS7MetadataRepositoryImpl.java:66)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.unregisterAll(ResourceAdapterDeploymentService.java:165)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:115)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]

19:03:59,835 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.ra.deployer."AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0": org.jboss.msc.service.StartException in service jboss.ra.deployer."AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0": JBAS010446: N'a pas pu d?marrer le d?ploiement RA [AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0]
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:116)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]
Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/C:/ProgramFiles/JBoss/jboss-eap-6.1/standalone/deployments/AcctFtCics-ear-1.0.0.ear/scortcicsecirar-3.1.0.rar/
	at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2449)
	at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:1104)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$AS7RaDeployer.doDeploy(ResourceAdapterDeploymentService.java:197)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:112)
	... 5 more
Caused by: org.jboss.jca.validator.ValidatorException: Severity: ERROR
Section: 6.5.3.2
Description: A ManagedConnectionFactory must be a non-null instance.
Code: com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory (ModuleClassLoader for Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader)

Severity: ERROR
Section: 5.3.1
Description: A ResourceAdapter must be a non-null instance.
Code: com.scort.ctg.cics.eci.jca.EciResourceAdapter (ModuleClassLoader for Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader)


> 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
>            Priority: Blocker
>
> 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  Wed Dec 27 02:48:00 2017
From: issues at jboss.org (Francis ANDRE (JIRA))
Date: Wed, 27 Dec 2017 02:48: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.17389.1514360880194@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508259#comment-13508259 ] 

Francis ANDRE edited comment on JBJCA-1363 at 12/27/17 2:47 AM:
----------------------------------------------------------------

This issue appears also in ironjacamar-1.0.17 in which I more interested since I am working with JBoss-EAP-6.1.


was (Author: fandremxw):
This issue appears also in ironjacamar-1.0.17 in which I more interested since I am wokring with JBoss-EAP-6.1.

> 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
>            Priority: Blocker
>
> 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  Wed Dec 27 02:52:00 2017
From: issues at jboss.org (Francis ANDRE (JIRA))
Date: Wed, 27 Dec 2017 02:52: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.17392.1514361120432@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508264#comment-13508264 ] 

Francis ANDRE edited comment on JBJCA-1363 at 12/27/17 2:51 AM:
----------------------------------------------------------------

Hi

I am trying to understand why my EIS RA is not activated when used under JBoss-eap-6.1 by testing my EIS RA using ALL trace logs for org.jboss.as.deployer in the ironjacamar-1.0.17-Final server. 

This exception is blocking the deployment of my EIS RA -- scortcicsecirar-3.1.0.rar -- on the  ironjacamar-1.0.17-Final server, precluding any debugging I can make with ironjacamar-1.0.17-Final.

For information, below is the server.log from a standalone JBoss-eap-6.1 configuration.

19:03:59,804 DEBUG [org.jboss.as.connector.logging] (MSC service thread 1-3) starting Inactive:InactiveResourceAdapterDeployment{module=Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader, connectorXmlDescriptor=org.jboss.as.connector.metadata.xmldescriptors.ConnectorXmlDescriptor at 61b97010, deployment='AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0', deploymentUnitName='AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0.rar', registration=org.jboss.as.controller.registry.ConcreteResourceRegistration at 556c5c8f, serviceTarget=org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget at 3d30dc19}
19:03:59,820 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) IJ020001: Required license terms for file:/C:/ProgramFiles/JBoss/jboss-eap-6.1/standalone/deployments/AcctFtCics-ear-1.0.0.ear/scortcicsecirar-3.1.0.rar/
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><description>Resource Adapter for accessing CICS through CTG (CICS Transaction Gateway)</description><display-name>Resource Adapter for CICS Transaction Gateway</display-name><vendor-name>SCORT S.A.</vendor-name><eis-type>CICS via CTG</eis-type><license><license-required>true</license-required></license><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.scort.ctg.cics.eci.jca.EciResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory</managedconnectionfactory-class><config-property><description>URL of the CTG</description><config-property-name>connectionUrl</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><description>Server (CICS) Name</description><config-property-name>serverName</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.scort.ctg.cics.eci.jca.EciConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.scort.ctg.cics.eci.jca.EciConnection</connection-impl-class></connection-definition><transaction-support>LocalTransaction</transaction-support><authentication-mechanism><authentication-mechanism-type>BasicPassword</authentication-mechanism-type><credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface></authentication-mechanism><reauthentication-support>true</reauthentication-support></outbound-resourceadapter></resourceadapter></connector>
*19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) IronJacamar=null
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) RaXML=null
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) ActivateDeployment=false*
19:03:59,820 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) CdMeta: <connection-definition><managedconnectionfactory-class>com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory</managedconnectionfactory-class><config-property><description>URL of the CTG</description><config-property-name>connectionUrl</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><description>Server (CICS) Name</description><config-property-name>serverName</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.scort.ctg.cics.eci.jca.EciConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.scort.ctg.cics.eci.jca.EciConnection</connection-impl-class></connection-definition>
19:03:59,820 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-4) Exception during unregistering deployment: org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0 isn't registered
	at org.jboss.jca.core.mdr.SimpleMetadataRepository.unregisterResourceAdapter(SimpleMetadataRepository.java:117) [ironjacamar-core-impl-1.0.17.Final-redhat-1.jar:1.0.17.Final-redhat-1]
	at org.jboss.as.connector.services.mdr.AS7MetadataRepositoryImpl.unregisterResourceAdapter(AS7MetadataRepositoryImpl.java:66)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.unregisterAll(ResourceAdapterDeploymentService.java:165)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:115)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]

19:03:59,835 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.ra.deployer."AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0": org.jboss.msc.service.StartException in service jboss.ra.deployer."AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0": JBAS010446: N'a pas pu d?marrer le d?ploiement RA [AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0]
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:116)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]
Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/C:/ProgramFiles/JBoss/jboss-eap-6.1/standalone/deployments/AcctFtCics-ear-1.0.0.ear/scortcicsecirar-3.1.0.rar/
	at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2449)
	at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:1104)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$AS7RaDeployer.doDeploy(ResourceAdapterDeploymentService.java:197)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:112)
	... 5 more
Caused by: org.jboss.jca.validator.ValidatorException: Severity: ERROR
Section: 6.5.3.2
Description: A ManagedConnectionFactory must be a non-null instance.
Code: com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory (ModuleClassLoader for Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader)

Severity: ERROR
Section: 5.3.1
Description: A ResourceAdapter must be a non-null instance.
Code: com.scort.ctg.cics.eci.jca.EciResourceAdapter (ModuleClassLoader for Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader)



was (Author: fandremxw):
Hi

I am trying to understand why my EIS RA is not activated when used under JBoss-eap-6.1 using ALL trace logs in the ironjacamar-1.0.17-Final server. 

This exception is blocking the deployment of my EIS RA -- scortcicsecirar-3.1.0.rar -- on the  ironjacamar-1.0.17-Final server, precluding any debugging I can make with ironjacamar-1.0.17-Final.

For information, below is the server.log from a standalone JBoss-eap-6.1 configuration.

19:03:59,804 DEBUG [org.jboss.as.connector.logging] (MSC service thread 1-3) starting Inactive:InactiveResourceAdapterDeployment{module=Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader, connectorXmlDescriptor=org.jboss.as.connector.metadata.xmldescriptors.ConnectorXmlDescriptor at 61b97010, deployment='AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0', deploymentUnitName='AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0.rar', registration=org.jboss.as.controller.registry.ConcreteResourceRegistration at 556c5c8f, serviceTarget=org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget at 3d30dc19}
19:03:59,820 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) IJ020001: Required license terms for file:/C:/ProgramFiles/JBoss/jboss-eap-6.1/standalone/deployments/AcctFtCics-ear-1.0.0.ear/scortcicsecirar-3.1.0.rar/
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><description>Resource Adapter for accessing CICS through CTG (CICS Transaction Gateway)</description><display-name>Resource Adapter for CICS Transaction Gateway</display-name><vendor-name>SCORT S.A.</vendor-name><eis-type>CICS via CTG</eis-type><license><license-required>true</license-required></license><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.scort.ctg.cics.eci.jca.EciResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory</managedconnectionfactory-class><config-property><description>URL of the CTG</description><config-property-name>connectionUrl</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><description>Server (CICS) Name</description><config-property-name>serverName</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.scort.ctg.cics.eci.jca.EciConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.scort.ctg.cics.eci.jca.EciConnection</connection-impl-class></connection-definition><transaction-support>LocalTransaction</transaction-support><authentication-mechanism><authentication-mechanism-type>BasicPassword</authentication-mechanism-type><credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface></authentication-mechanism><reauthentication-support>true</reauthentication-support></outbound-resourceadapter></resourceadapter></connector>
*19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) IronJacamar=null
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) RaXML=null
19:03:59,820 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) ActivateDeployment=false*
19:03:59,820 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-4) CdMeta: <connection-definition><managedconnectionfactory-class>com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory</managedconnectionfactory-class><config-property><description>URL of the CTG</description><config-property-name>connectionUrl</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><description>Server (CICS) Name</description><config-property-name>serverName</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.scort.ctg.cics.eci.jca.EciConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.scort.ctg.cics.eci.jca.EciConnection</connection-impl-class></connection-definition>
19:03:59,820 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-4) Exception during unregistering deployment: org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0 isn't registered
	at org.jboss.jca.core.mdr.SimpleMetadataRepository.unregisterResourceAdapter(SimpleMetadataRepository.java:117) [ironjacamar-core-impl-1.0.17.Final-redhat-1.jar:1.0.17.Final-redhat-1]
	at org.jboss.as.connector.services.mdr.AS7MetadataRepositoryImpl.unregisterResourceAdapter(AS7MetadataRepositoryImpl.java:66)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.unregisterAll(ResourceAdapterDeploymentService.java:165)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:115)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]

19:03:59,835 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.ra.deployer."AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0": org.jboss.msc.service.StartException in service jboss.ra.deployer."AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0": JBAS010446: N'a pas pu d?marrer le d?ploiement RA [AcctFtCics-ear-1.0.0.ear#scortcicsecirar-3.1.0]
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:116)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_80]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_80]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_80]
Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/C:/ProgramFiles/JBoss/jboss-eap-6.1/standalone/deployments/AcctFtCics-ear-1.0.0.ear/scortcicsecirar-3.1.0.rar/
	at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2449)
	at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:1104)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$AS7RaDeployer.doDeploy(ResourceAdapterDeploymentService.java:197)
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:112)
	... 5 more
Caused by: org.jboss.jca.validator.ValidatorException: Severity: ERROR
Section: 6.5.3.2
Description: A ManagedConnectionFactory must be a non-null instance.
Code: com.scort.ctg.cics.eci.jca.EciManagedConnectionFactory (ModuleClassLoader for Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader)

Severity: ERROR
Section: 5.3.1
Description: A ResourceAdapter must be a non-null instance.
Code: com.scort.ctg.cics.eci.jca.EciResourceAdapter (ModuleClassLoader for Module "deployment.AcctFtCics-ear-1.0.0.ear.scortcicsecirar-3.1.0.rar:main" from Service Module Loader)


> 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
>            Priority: Blocker
>
> 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  Wed Dec 27 10:53:00 2017
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Wed, 27 Dec 2017 10:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9635) jdr throws
 IllegalArgumentException if server is not started
In-Reply-To: <JIRA.12725956.1513935394000@Atlassian.JIRA>
References: <JIRA.12725956.1513935394000@Atlassian.JIRA>
	<JIRA.12725956.1513935394000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725956.1513935394000.17576.1514389980213@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFLY-9635:
-------------------------------
    Attachment: jboss-eap-7.1.0.log
                wildfly-11.0.0.Final.log


> jdr throws IllegalArgumentException if server is not started
> ------------------------------------------------------------
>
>                 Key: WFLY-9635
>                 URL: https://issues.jboss.org/browse/WFLY-9635
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>            Reporter: Marek Kopeck?
>            Assignee: Brad Maxwell
>            Priority: Blocker
>         Attachments: jboss-eap-7.1.0.log, wildfly-11.0.0.Final.log
>
>
> *Description of the issue:*
> jdr throws IllegalArgumentException if server is not started
> *Steps to reproduce:*
> # do *not* start the server
> # ./jdr.sh
> *Actual results:*
> {noformat}
> [mkopecky at dhcp-10-40-4-226 bin]$ ./jdr.sh
> Initializing JBoss Diagnostic Reporter...
> Trying to connect to http-remoting localhost:9990
> Starting embedded server
> Exception for embed-server --std-out=echo : Task java.util.concurrent.FutureTask at 6631f5ca rejected from java.util.concurrent.ThreadPoolExecutor at 5ace1ed4[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> Exception for stop-embedded-server: Task java.util.concurrent.FutureTask at 31e5415e rejected from java.util.concurrent.ThreadPoolExecutor at 5ace1ed4[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> Exception in thread "main" java.lang.IllegalArgumentException: Error handling command: /subsystem=jdr:generate-jdr-report()
> 	at org.jboss.as.cli.scriptsupport.CLI.cmd(CLI.java:248)
> 	at org.jboss.as.jdr.CommandLineMain.main(CommandLineMain.java:120)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> Caused by: org.jboss.as.cli.CommandLineException: The connection to the controller has not been established.
> 	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:804)
> 	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:823)
> 	at org.jboss.as.cli.scriptsupport.CLI.cmd(CLI.java:241)
> 	... 3 more
> [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 Dec 27 16:57:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 27 Dec 2017 16:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9642) CVE-2016-9589
In-Reply-To: <JIRA.12726019.1514248263000@Atlassian.JIRA>
References: <JIRA.12726019.1514248263000@Atlassian.JIRA>
	<JIRA.12726019.1514248263000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726019.1514248263000.17673.1514411820394@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-9642.
-----------------------------
    Resolution: Duplicate Issue


duplicate of WFLY-7725

> CVE-2016-9589
> -------------
>
>                 Key: WFLY-9642
>                 URL: https://issues.jboss.org/browse/WFLY-9642
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Hiroaki Naito
>            Assignee: Jason Greene
>            Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Dec 28 08:37:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 28 Dec 2017 08:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2200) NPE when structured DT
 output field is null
In-Reply-To: <JIRA.12726073.1514468190000@Atlassian.JIRA>
References: <JIRA.12726073.1514468190000@Atlassian.JIRA>
	<JIRA.12726073.1514468190774@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726073.1514468190000.17889.1514468220095@Atlassian.JIRA>

Matteo Mortari created DROOLS-2200:
--------------------------------------

             Summary: 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  Thu Dec 28 10:14:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 28 Dec 2017 10:14:00 -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.1514474021213@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726075.1514474021000.17903.1514474040088@Atlassian.JIRA>

Matteo Mortari created DROOLS-2201:
--------------------------------------

             Summary: 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


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  Thu Dec 28 10:21:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 28 Dec 2017 10:21:00 -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.17905.1514474460182@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-2201:
-----------------------------------
    Attachment: screenshot-1.png


> 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
>
>
> 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  Thu Dec 28 10:21:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 28 Dec 2017 10:21:00 -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.17907.1514474460299@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508342#comment-13508342 ] 

Matteo Mortari commented on DROOLS-2201:
----------------------------------------

Example for Decision Table output column:
 !screenshot-1.png|thumbnail! 

> 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
>
>
> 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  Thu Dec 28 10:23:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 28 Dec 2017 10:23:00 -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.17909.1514474580322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-2201:
-----------------------------------
    Attachment: screenshot-2.png


> 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  Thu Dec 28 10:23:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 28 Dec 2017 10:23:00 -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.17911.1514474580403@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508343#comment-13508343 ] 

Matteo Mortari commented on DROOLS-2201:
----------------------------------------

Example for Context result
 !screenshot-2.png|thumbnail! 

> 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  Sat Dec 30 09:23:00 2017
From: issues at jboss.org (Gopal krishna (JIRA))
Date: Sat, 30 Dec 2017 09:23: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.1514643774000@Atlassian.JIRA>
References: <JIRA.12726085.1514643774000@Atlassian.JIRA>
	<JIRA.12726085.1514643774669@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726085.1514643774000.18192.1514643780196@Atlassian.JIRA>

Gopal krishna created WFLY-9643:
-----------------------------------

             Summary: 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: Application Client
            Reporter: Gopal krishna
            Assignee: Stuart Douglas
            Priority: Blocker


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".

This 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  Sat Dec 30 11:36:00 2017
From: issues at jboss.org (Gopal krishna (JIRA))
Date: Sat, 30 Dec 2017 11:36: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.18215.1514651760136@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gopal krishna updated WFLY-9643:
--------------------------------
    Description: 
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

  was:
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".

This didnt see this issue in jboss 7 and  WAS



> 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: Application Client
>            Reporter: Gopal krishna
>            Assignee: Stuart Douglas
>            Priority: Blocker
>
> 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  Sun Dec 31 10:57:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 31 Dec 2017 10:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3482) Remove deprecated
 org.jboss.as.controller.NoSuchResourceException
In-Reply-To: <JIRA.12726088.1514735792000@Atlassian.JIRA>
References: <JIRA.12726088.1514735792000@Atlassian.JIRA>
	<JIRA.12726088.1514735792222@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726088.1514735792000.18229.1514735820112@Atlassian.JIRA>

Brian Stansberry created WFCORE-3482:
----------------------------------------

             Summary: Remove deprecated org.jboss.as.controller.NoSuchResourceException
                 Key: WFCORE-3482
                 URL: https://issues.jboss.org/browse/WFCORE-3482
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 4.0.0.Alpha6


Class was deprecated in March 2015 and is not used in WildFly Core or in full WildFly.  It was never something meant for use outside of the management kernel, so the odds any external extensions use it are low.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Dec 31 11:42:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 31 Dec 2017 11:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3482) Remove deprecated
 org.jboss.as.controller.NoSuchResourceException
In-Reply-To: <JIRA.12726088.1514735792000@Atlassian.JIRA>
References: <JIRA.12726088.1514735792000@Atlassian.JIRA>
	<JIRA.12726088.1514735792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726088.1514735792000.18231.1514738520146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3482:
-------------------------------------
    Priority: Minor  (was: Major)


> Remove deprecated org.jboss.as.controller.NoSuchResourceException
> -----------------------------------------------------------------
>
>                 Key: WFCORE-3482
>                 URL: https://issues.jboss.org/browse/WFCORE-3482
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 4.0.0.Alpha6
>
>
> Class was deprecated in March 2015 and is not used in WildFly Core or in full WildFly.  It was never something meant for use outside of the management kernel, so the odds any external extensions use it are low.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Dec 31 18:15:00 2017
From: issues at jboss.org (Dean Schulze (JIRA))
Date: Sun, 31 Dec 2017 18:15: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.1514762045010@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726089.1514762045000.18234.1514762100260@Atlassian.JIRA>

Dean Schulze created WFLY-9644:
----------------------------------

             Summary: 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


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)

